The “A”-word

Everywhere I go I hear similar stories about EA teams struggling to break through misconceptions and  skepticism to provide real value to the business. So much has been said about EA value that I feel exhausted even thinking about it. Instead, I wanted to ponder the possibility that we have a branding problem and the word “architecture” is our own enemy.
EA is at its best when working closely with business, helping analyze and steer decisions, strategic or tactical. However, business often sees us as technologists only. In their eyes we are those people who can evaluate technology, size the servers, wire the applications together etc. They often don’t see us as partners in strategic alignment or innovation discussions that occur outside of the realm of IT. This is unfortunate but how can you blame them?
Historically EA comes from IT. The appreciation for architecture in IT started at the  application or the system level and only intensified as the systems became more fragmented and distributed, thus needing good architecture. It wasn’t until much later when Enterprise Architects realized that they need to develop a holistic view of the enterprise which goes beyond technology.  Unfortunately, business folks didn’t necessarily come to this realization at the same time.
People who call themselves Enterprise Architects usually “graduated” from senior development or system engineering roles. Enterprise Architect became the sought-after title that was synonymous with the pinnacle of career in IT (?!) (by  the way, I’m not trying to disparage others…I myself walked the same path). As for business, they used to speak with Software Engineers and now they are asked to speak with Architects. Guess what? For the most  part, they are the same people doing very similar work. The main difference is the title. Can we really blame the business for treating architecture as the function of IT then?
The Open  Group does not help either. TOGAF, while it features business architecture as a component of EA, it remains very IT-centric. In fact, it is very difficult to see it as anything other than a framework for developing IT systems.

Interestingly, Business Architecture now tries to surface as the discipline that attempts to provide what Enterprise Architecture failed to deliver – business-focused, value-centric approach to  architecting the enterprise. Granted, Business Architecture Guild firmly positions business architecture under the umbrella of enterprise architecture together with IT architecture. However, there are voices that say that business architecture is really what enterprise architecture should have been. This is usually  accompanied by  the statements that Business Architect is this new cool role that everyone should aspire to.  We shall see how this turns out but I suspect that the “A-word” will get in the way again. Especially that most organizations promote Business Architect role from within IT and use the ranks of Business Analysts as their basis. The challenge here is two-fold. One is that Business Analysts often reside within the IT organization, which again leads to the IT stigma. Two is that many Business Analysts usually focus on business requirement analysis and user acceptance testing. They don’t necessarily have the breadth of technical background and experience to perform in the Enterprise Architect capacity.

In any case, getting out of IT shadow without losing IT perspective is likely to continue to be a challenge for EA and using the term “architecture” is not helping. “Architecture” is not likely to be associated with more than technology by many, especially on the business side. Fighting it is counterproductive. Instead EA teams could eliminate the term “architecture” from their name and from their vocabulary. Instead, they may consider saying “strategy”, “business alignment” or something that doesn’t scream “technology”.
Perhaps EA teams could be placed under the office of Strategy Management or under the office of Business Innovation instead of some IT department.

 

Advertisements

New town, same story…

I have recently changed employers – different industry, different structure, and different culture. I have been asked how a switch like this works for an Enterprise Architect and how transferable is the experience in EA in general. Every time this question comes up I remember a line uttered by late Patrick Swayze in the 80s classic, Roadhouse. “Ah, you know, new town, same story”. It pretty much sums it up.

Amazingly, most companies struggle with the same challenges. To name a few:

  • Too many “top” business priorities.
  • Business that proposes technology solutions rather than specifying requirements
  • Projects that define architecture only within their scope, and usually lack broader perspective.
  • Silo thinking
  • Architecture reviews, occurring way to late in the process, if at all.
  • Limited knowledge of the existing technology landscape.
  • Lack of clarity of what the architecture of the future state looks like.

Yes, the challenges are usually the same and in that sense the EA discipline has the same applicability. However, the difference lies in the approach to establishing and sustaining the enterprise architecture function. In that case the variations may be many and driven by factors like these:

Level of architecture skills within the IT organization. If the organization already has people with architecture skills but lacks architecture structure and discipline, you can focus on consolidating and standardizing the approach of existing architects. If there are no or few architects in the organization then you have two choices, hire more architects or develop architects from the existing pool of talent. In the first situation the focus will be on having the architects do architecture in a standard way, perhaps leveraging the best practices from each one of them and normalizing them using some industry framework as a guide. The second case gives you more freedom in establishing the framework first and then simply bringing the architects into it, either by hiring or training.

Level of openness of the organization to reuse solutions across established, historical boundaries. Yes, there are silos everywhere. They can be defined by organizational or geographical boundaries and are usually hard to break. The main challenge here lies in convincing the business that reuse across established fiefdoms is beneficial not only to the whole enterprise but to the individual fiefdoms too. This is a process and I believe that it is naive to expect total commitment from the entire enterprise. After all, reuse often means loss of fiefdom’s control over a piece of technology or over a process. It may be hard to swallow as it gets personal to those in charge. Strong executive leadership, especially from the business side, is the key to success in this area.

Executive support for the EA function.  When CIO (or any CxO who is in charge of EA function) understands the role of EA function, he or she can take the lead in setting the right tone in the entire organization by explaining that role. The right message and right tone goes a long way in ensuring that the organization adopts the big picture thinking and allows EA to facilitate it. Executive support is crucial and without it very little can happen. In absence of firm and vocal support, EA needs to spend a lot of energy explaining what it does and convincing the organization that its actions will benefit the company. While communication and stakeholder management are important components of EA function, it cannot be just about explaining and justifying. If you get stuck in that mode you will not have much energy left to actually DO enterprise architecture.

General understanding of the EA function. Okay, so the CIO gets it. However, everybody and their mother-in-law is an “architect” these days. Casual labeling people as architects and lack of some standardization in the role definition led to many misconceptions. Those misconceptions led to a situation that is worse than just not knowing what EA does. It created a situation where people believe that they completely understand the role of EA but their own notions are vastly different from those of other people. Moreover, they can be vastly different from the somewhat established definition (FEAPO, Open Group etc.) of what EA function is. The answer to this problem is of course, educate, show, and then educate again. This is easier said than done because once you start “educating”, you risk being seen as this theoretician who is all talk and no walk. That is why teaching must ALWAYS be accompanied by doing. Hopefully “doing” results in some quick wins that only strengthen the EA credibility and open some eyes and ears for more education.

This was not meant to be an exhaustive list of factors that influence the evolution of an EA practice. However, it seems that those are the most common ones. I have just returned from the EA Summit conference in DC and many conversations I had there seem to confirm it. In any case, EA is a journey, and we don’t walk it for the benefit of EA but for the benefit of an organization that we are part of. In that spirit, adjust EA to the organization and not the organization to EA. Flexibility, compromise, and controlled pace are the ways of the land.

Cheers. Happy EAing!

 

Preaching to the choir

ApplauseIt has been a few weeks since the Gartner Enterprise Architecture Summit conference in Grapevine, Texas. It continues to be my favorite conference, probably because it seems to be the only US-based conference dedicated entirely to the EA discipline. For me, attending this conference has three benefits. One, it allows me to validate initiatives and approaches, that I as an architect push within my organization. Two, it allows me to have numerous conversations with my peers about the state of their EA practice. This is, of course, invaluable because it puts the “reality” lens in front of what Gartner says. Three, it exposes me to information about developing trends in EA.

At the last conference, one of the recurring themes appeared to be “Vanguard EA” and how it plays in the era of digital business. The key premise here is that the Vanguard EA is the part of EA discipline that is about looking into the future, about innovation, and about steering the enterprise in close partnership with Business. This is in contrast with the Foundational EA, which is more about traditional, perhaps more reactive and IT-focused practice. In other words, Foundational EA is what most EA organizations are today, while Vanguard EA is this emerging trend which represents the place where most EA organizations would like to be. From what  I  could gather, Gartner believes that there will always be room for both Foundational and Vanguard EA, but in order to thrive in the digital business era organizations must evolve their EA practices beyond their foundational character.
This is great and I couldn’t agree more. Here is the disconnect though… Virtually in all hallway conversations I had at the conference, attendees confirmed that the idea of Vanguard EA is a very elusive dream, as most EA organizations still struggle to be invited to  the “business” table.  It is true even for what Gartner would consider foundational  EA work. In  one of the sessions, Gartner speaker suggested that we as Enterprise Architects should invite ourselves to the business table,  by demonstrating the value that  we bring to business discussion. This is nice, but also strikes me as a little whiny. It’s like a kid saying that if another kid doesn’t want to play with him then he would just keep  bringing him candy in hopes that one day he invites him  to  play. This is a precarious position to be in… and it brings me to the point of this post. It seems that Gartner may be preaching to the choir. Don’t tell us, architects that Vanguard EA is a way of the future, tell the business!

I don’t have the official statistics but I am willing to bet that the vast majority of attendees were architects or managers of architecture organizations. Very few attendees were true business leaders. In one of the closing sessions, the audience was asked “how can we make this conference better”. One of the attendees responded, “offer a two-for-one deal, where you get your conference pass for free if you bring a business person with you!”. I’m not sure if this particular idea is feasible but it clearly shows that many of the attendees share my sentiment. So how about it Gartner? Perhaps it is time to stop preaching to the choir and direct your message to business leaders instead.

 

EA 2020 – Crystal Ball

Recently, someone asked me what my thoughts were on the long-term future of the practice of the enterprise architecture (EA). In the same sentence, that person said “…say in 2020?”.crystalball

First, I was struck by the realization that what we consider “long-term” is not measured in decades anymore.  Let that sink in for a few seconds. 2020 is not even six years away. I think what this question conveys is the acceptance of the new reality, in which the time horizon for reliable predictions has shrunk considerably. After  all, iPhone was born only in 2007 and Twitter in 2006. Not too long ago we were celebrating the dawn of digital point-and-shoot cameras and now they are obsolete. Things are changing and they are changing at the ever-increasing pace. Predicting future, and thus planning, is becoming rather difficult. Now multiply that by the level of complexity associated with a typical large enterprise and the emerging picture is overwhelming if not downright scary.

What does it mean for the practice of enterprise architecture? Given my previous statements, I am very skeptical about my or anyone’s ability to predict what the future holds even if it is only six years out. However, I have some thoughts about what the practice of EA should look like in 2020 to remain relevant.

In 2020, the enterprise architecture function is driven from the business side of an enterprise rather than from the IT side. In practical terms it may mean that the EA organization reports to a CEO or CFO rather than to a CIO or CTO. This is not typical for most organizations today  and it is at least partially responsible for enterprise architecture’s excessive focus on technology.

In 2020, Enterprise Architects are well versed in the language of business yet conversant in IT “dialects”. They have business as well as technology training and experience. This means that at least some architects come from the ranks of business rather than from the ranks of technologists. In either case, they are able to translate business concerns to technology concerns and vice versa.

In 2020, business architecture gains more prominence as an indispensable component of enterprise architecture. In fact, it assumes the role of the driving force for other architecture domains. Business architecture has a synergistic relationship with the Business Process Management (BPM) discipline and the two are largely indistinguishable, especially in the area of planning and modeling.

In 2020, Enterprise Architects don’t talk much about architecture frameworks. Instead, the main topic of conversation is the business value. Frameworks are still there but serve only as a reference and are used only to the extent that they contribute to more efficient operation of the enterprise architecture practice. They provide structure and guidance when setting up the practice but as the practice matures they fade away from the enterprise architecture vernacular. Consequently, enterprise architecture certifications lose their momentum as they emphasize the framework-centric knowledge.

In 2020, the primary role of Enterprise Architects is to advise and orchestrate. They analyze how market, social, and technology influencers affect the business. They look at influencers and advise on business opportunities that those influencers create. They also look at those influencers and advise on how to mitigate the risks that they may pose.

Enterprise Architects and business are partners in formulation of enterprise strategy. They develop strategic options, and advise on selecting the best one. The options are not just technology-centric. Instead, they include orchestrated application of process, people, and technology. More so than before, the orchestration involves mediation between internally sourced services and those provided by external partners.

In 2020, execution of enterprise strategy is monitored and facilitated through efficient management of project portfolio, which continually takes the architecture description of the current and target states as input. Enterprise architecture practice ensures that the architecture target state is accurate and known at any given point in time. Alignment with architecture targets is facilitated through architecture governance, which is integrated with both ideation and solution delivery processes.

In 2020, enterprise architecture is a recognized profession. There is a well-known, common set of knowledge and a common set of skills that can be expected from a person called an Enterprise Architect. There are no more calls from recruiters seeking to hire Enterprise Architects with “strong C# and Java skills” ( I actually received calls like that). Clarity around what Enterprise Architects do allows definition of career paths leading into and out of Enterprise Architect role.

Like I said, I don’t really know where the discipline of enterprise architecture will be in 2020. Predictions can be tricky and generalizations can be dangerous. I suspect that at least some of the thoughts expressed in this article may prove to be rather aspirational. Enterprise architecture must focus on enabling business value and as such must be tailored to individual business needs. This alone may mean that enterprise architecture will have many shapes and forms in the future. I hope that at least the core of what it is will be normalized and have some resemblance to what I described above.

I’m sure you have your own opinions about the state of enterprise architecture in 2020. Will it thrive or will it be diminished? Will it still be heavy on technology or will it focus more on business? Will it be a separate discipline or will it

blend with others? Please, share your thoughts.

Happy architecting!

Integrating Enterprise Architecture – practical thoughts

1902 Glider from rear

Learning to fly. We didn’t get the Dreamliner right away.

It is hard to get excited about enterprise architecture frameworks these days…or maybe it’s just me. Of course, the framework-centric “certification industry” is in full gear producing “certified architects” but just like many other infatuations this one will pass too. There is already evidence that the enterprise architecture frameworks are entering disillusionment phase where the notions of sliver-bullet approach to enterprise architecture have failed (see Gartner Hype Cycle for Enterprise Architecture). With any luck, the streamlined, practical and value oriented approach to enterprise architecture will emerge from the through of disappointment.

Does it mean that the architecture frameworks failed to deliver? Yes and No.
Yes, because they failed to deliver the silver bullet. However, in all fairness, most frameworks never claimed that they had all the answers. In fact, they usually state that the best approach is to take those elements that work for your organization, and tailor them to the organization’s specific needs. In that sense, the frameworks failed to deliver what they never promised. No, because they provided a way to conduct discussions about the enterprise architecture function in a structured fashion. As flawed as they may be, they do embody some collective architecture experience, which can be considered a best practice.

I can’t shake the feeling that many mainstream enterprise architecture frameworks are a better fit for smaller-size companies or for individual segments of a large enterprise. They seem to be assuming the process and the flow of information that are mostly undisrupted by conflicting priorities. They seem to underestimate the complexity and cost of managing architecture information on a larger scale. This is ironic because enterprise architecture by definition makes more sense for large, complex environments where aligning change to strategic goals truly is a “full-time job”.

Implementation and application of some architecture framework as the foundation of the enterprise architecture function is usually a good idea but doing it in context of a large enterprise can be challenging. There are distributed decision centers, often fragmented architectural information, large number of stakeholders,  and many, many moving parts. In this context a lot of energy goes into efforts that aim to integrate the disparate processes and information so that the enterprise architecture function can be executed in a coherent manner that is worthy of the enterprise scale. Enterprise architecture frameworks don’t provide complete answers to this challenge. Instead, they give us a picture of a somewhat idealistic future state with the hope that we figure out how to get there.

Situation like this may call for a pragmatic approach to implementing the function of enterprise architecture. To be perfectly clear, “pragmatic” doesn’t mean devoid of structure and solid footing. It means “systematic”, “gradual” and “environment-appropriate”. It means not taking the frameworks literally but applying what fits YOUR organization, and pushing for change at the pace that does not overwhelm. One way to articulate this approach is through the set of guiding thoughts that may sound like this:

  • Know why you want enterprise architecture TODAY. Focus on generating value for business sooner rather than later. Enterprise architecture usually enables good things in the future but may struggle to deliver immediate benefit. Find the immediate one! It may be in the least expected area, like using architecture models for impact analysis or project team onboarding. If you can realize short-term benefits and point to quick wins with architecture, you will be able to gain enough support to realize other, lofty goals.
  • Be mindful about how much architecture information you can manage. Enterprise architecture function has to be sustainable.  Cost-benefit analysis must be done upfront and may lead to compromises in how you describe architecture.  Favor breadth over depth and don’t be tempted by desire for more detail unless you have clear understanding of how it will contribute to the net value for business.
  • Models developed organically in silos will not blend well. Out-of-the-box modeling languages are too ambiguous to allow consistent integration across siloes. Consider focusing on a subset of element types first and establish a set of rules on top of a standard modeling language.
  • Build on the existing foundation. You already have processes. Use them, tweak them, repurpose them. Big change is expensive.
    You already have a language. It is the one that the business uses. Use it where you can and don’t force the business into enterprise architecture vernacular. Remember that the business cares about value and not about your cool architecture framework.
  • Establish architecture taxonomy first. Considering the previous bullet, build and publish the catalogs of common architectural elements like processes, applications or services. Make sure to have enterprise-wide agreement to use the catalogs when discussing those common elements.  Again, don’t force the architecture language on all stakeholders. Instead, use theirs and translate internally.
  • Establish information ownership and governance. Controlled management of change inspires trust. Whether it applies to catalogs of apps, services, or models, change must be managed to ensure that the information is reliable. However, don’t go overboard with control as it may create perception of bloated bureaucracy. Focus your control efforts on big-ticket items that are used to link information across many sources. Examples of that could be an application portfolio or a service portfolio.
    Interests of all stakeholders must be represented when the change is proposed. For that reason, establish the role a data steward and position it to facilitate stakeholder collaboration and consensus building.
  • It’s about information, not about the tools. Invest in information and ensure it is expressed in a standard way. Exiting standards like BPMN, ArchiMate or UML may be a good start. Standard-based approach increases the chance of portability of the underlying data between different tools. Start with simple set of tools and once you learn how to manage the information you will be in better position to introduce some big, expensive tool down the road, if you really need one. Vendors of “Cadillac” tools want you to believe that their offering will solve the enterprise architecture problems. Their approach often requires big upfront investment and managing information in a way prescribed by the tool. The problem is that if you don’t know what you want it will be very easy for the vendors to sell you anything. Learn where the value is first.
  • It’s about people. People don’t like change but will lie about it. You may quickly realize that in most people’s minds change is good only when it is someone else who has to change. This may be amplified in highly siloed environments where organizational and ownership structures have been fossilizing over the long periods of time.
    Securing the executive support for the enterprise architecture initiative goes a long way. Strong and firm leadership from the top with clear messaging about the value proposition is a must. Without it, you will get nods and smiles but not much cooperation. The executive support can be thought of as a stick in a “carrot and stick” combo. The carrot takes us back to the first bullet of this rambling, which talks about short-term benefits. Build bottom-up advocacy by showing immediate benefits from the integrated enterprise architecture information and play into people’s self-interest.

It goes without saying that the above thoughts may not apply to every situation. However, I suspect that at least some of them may be worth considering whenever the implementation of the enterprise architecture function is undertaken.
Enterprise architecture function on a large scale can be very challenging. Chances are that if you are reading this post, you have tried or are trying to advance the enterprise architecture in your own environment.  What are your experiences? What approach really worked for you? What didn’t? I would love to hear from you.