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!

 

Advertisements

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!

“Like a Rock” – Business Capabilities and EA

“…My hands were steady
My eyes were clear and bright
My walk had purpose
My steps were quick and light
And I held firmly
To what I felt was right
Like a rock…” – Bob Seger

Enterprise architecture, as a function of an enterprise, continues on its quest to deliver meaningful and recognizable value for the business. Of course, if you ask an IT person the value of enterprise architecture is obvious and it requires no further explanation. Knowing where the enterprise is and where it is going are the key value enablers for those who are tasked with implementation of the strategy. In IT, those are developers, testers, analysts, project managers, solution architects, etc. Increased predictability of the solution delivery is an example of one of those value propositions. However, this value proposition is somewhat inward looking and only indirectly visible to business.

Enterprise architecture is not just about solution delivery. It is also, and perhaps mostly, about strategic planning and portfolio management. After all, Enterprise architect’s job or any architect’s job does not begin after the blueprints are created but way before the first blueprint lines get drawn. In fact, it is the creation of that blueprint that is the source of most of the value from enterprise architecture. Mind you, when I write “blueprint”, I mean it in a larger sense as in “plan” or “strategy” and not just as a set of diagrams.

Strategic planning is predicated on existence of the business mission and the business model that serve as a driving force for everything that the enterprise does. Going further, a concept of a business capability emerged as a useful way to describe what a business needs to do to fulfill that mission in a context of a specific business model. A useful way to think about capabilities is as of individual skills that can be attributed to an organization and delivered through the combination of people, process, information, and technology.

Incidentally, enterprise architecture also looks at people, process, information, and technology. It does it through architecture layers often described as Business Architecture, Information Architecture, and Technology Architecture. While enterprise architecture goes deeper into concepts associated with each layer, capabilities themselves remain at a high level and focus on the question of “what the enterprise does”. Remember, it is not about how it does it, only about what it does.

So what is it that an enterprise does? Surprisingly (or not), there is a set of capabilities that every enterprise has regardless of the nature of the business, location, or culture. Clear examples could be Human Resources Management, Financial Planning, External Relations Management, or Risk Management to name a few. Those are generic ones and they apply to virtually every enterprise with the difference being of course in how those capabilities are realized. More specialized capability models emerged for some industries, which add the industry-specific capabilities. For example, ACORD or Panorama 360 are capability models that are specific to insurance industry and introduce capabilities like Claims Management or Contract Acquisition.

Regardless of what the set of capabilities is, whether it is one of the standard sets or a custom one, the key characteristic of that set is that it is very stable. It doesn’t change unless the enterprise overhauls its business model or significantly changes its purpose. What changes is how those capabilities are realized through people, process, information, and technology.

Given the relative stability of capabilities, they present an interesting opportunity for becoming an anchor for other enterprise architecture concepts. In other words, processes, applications, data, etc., all interact together to realize very specific capabilities. In an enterprise architecture model it may look somewhat like this:

ArchiCapabilities

Fig 1. Example of a conceptual enterprise architecture meta model with capabilities

Processes, Services, Application Components etc., linked to capabilities show HOW the enterprise implements WHAT the enterprise does or WHAT it aspires to do. Now the conversations with business can be more meaningful. Capability is a concept, with which the business is familiar. It can associate costs, efficiency, and quality with each capability when making investment decisions. Since capabilities are usually stable, results of those decisions can be reliably assessed at that level regardless of nuances of underlying implementations.

Imagine a heat-map which shows all of the enterprise capabilities as rectangles. Each rectangle has a different size which illustrates relative annual operating cost associated with a capability. Each rectangle can have a color, which illustrates the relative level of annual investment in a capability. It is a simple picture that can clearly show misaligned investments and drive the discussion about change. In another version the rectangles can be colored to represent relative complexity. Guess what, chances are that high complexity areas will overlay areas with high operational costs. Wouldn’t you like to have those pictures with you, when discussing budget for reducing the technical debt in your IT systems? In yet another version, the rectangles can be coded to indicate relative importance to business. Do the levels of investment in each capability match their level of business importance?

HeatMap

Fig 2. Example of high-level capability heat-map

Now, don’t take that as a statement that an enterprise has to be broken up into a handful of capabilities and analysis done at that level. In reality, high-level capabilities can and should be decomposed into lower-level capabilities that provide more granularity and may be more meaningful in business discussions. Those lower-level capabilities are likely to serve as more appropriate anchors for enterprise architecture concepts that aim to describe HOW the enterprise operates. The combination of enterprise architecture information about processes, information and technology rolled up into lower-level and then high-level capabilities tells the whole enterprise story. Costs, quality, and efficiency data collected at lower-level architecture elements like processes, applications, databases can be aggregated by capabilities and used to present the enterprise architecture in business terms. In fact, this ability to collect, aggregate, illustrate, and influence is the key to success for any enterprise architecture practice.

Approach to enterprise architecture, which is based on business capability models, emerges as a mainstream force that promises to bridge the gap between IT and business. Like a rock, business capabilities are stable and largely immovable. They are what business understands. Like a rock, they can be the foundation for enterprise architecture efforts, providing a common reference point for architects and business professionals.

“…Like a Rock…”, or more accurately, like the Rosetta Stone?

Practical EA may be key to its relevance

Most Architects and probably most IT people understand the benefits of a well-functioning Enterprise Architecture capability. Can we say the Business understands it too?

Developing and sustaining EA capability in context of a large enterprise can be very challenging. It is so because organizations usually start with the lot of baggage that has accumulated over the years. The baggage being the organizational silos, technical debt or company culture to name a few. For that reason it is very important to have a clearly articulated value proposition for EA. The value proposition must resonate with the Business and offer some short-term benefits in addition to long-term benefits. Having articulated the value, it is important to focus on delivering on those short-term promises because the failure to do so may undermine EA’s ability to realize the long-term ones. What does it mean exactly, you ask? It means that you may have to take a practical approach to Enterprise Architecture as opposed to a holistic one. It may mean the following:

  • Using architecture frameworks as guides and not as exact blueprints for EA.
  • Maximizing the reuse of existing processes in your organization, however imperfect they may be.
  • Relying on simple and familiar tools instead of pursuing the holy grail of a tool that promises to solve all EA problems.
  • Limiting the amount of architectural information to the level that can be reliably managed while still providing tangible value.
  • Establishing controls to ensure that architectural information maintains its currency over time.

Of course, the list can go on. The bottom line is that in order to run you have to learn how to walk first. Business may never let EA “run” if they can’t see that it can walk straight.

Join me at #SATURN14 for a brief talk about a practical approach to integrating Enterprise Architecture.

Certifiably Influential?

CertificateRecently, I have been involved in several conversations about the Architect certifications. It is an interesting topic that comes up more and more as the number of people who call themselves Architects increases. It is only natural. After all, when every other person is an Architect, how do you tell the “good” one from the “average” one. One answer may be that only certified ones are “good”…or is it?

Before we get any further, I would like to recall the era when IT certifications became popular. They started as a way for people with limited experience in the field to move up in the ranks or get that dream job. As more and more people obtained the certifications those with real experience started feeling left out. It seemed that they were the only ones without the certification and the employers fanned the flames. So what is one to do? Get certified of course! In the end almost everyone with some skills got certified and the quest for differentiation had to start over. Oh what an opportunity for the certification vendors!

I believe that this game continues now with the Architect certifications. Some certifications are based purely on a study+exam model. Others attempt to add the component of experience assessed through personal interviews. In the end it all boils down to being able to understand number of architectural concepts and explain them to others. In other words, it’s largely about taxonomy and mechanics. It has little to do with the overall skills of an Architect.

In the spirit of full disclosure, I don’t hold any Architect certification and don’t plan on getting one unless the game described above forces me to do so. I do have a TOGAF certification obtained through my employer but that’s just a framework and one of many at that.

As you no doubt have guessed, I believe that the Architect certifications are worthless from the point of view of experienced Architects (can there be any other kind?). I think that anyone who practiced architecture, especially Enterprise Architecture, will agree that architecture can be seen as part science and part art.  Often dealing with ambiguity, varying levels of abstraction, and uncertainty of long-term strategies. It requires a blend of vision and pragmatism and often relies on influence rather than authority. In fact, influence and compromise seems to be the name of the game, the modus operandi of successful Architects in the industry.

Can you certify one’s ability to influence? How about one’s ability to compromise? I don’t believe you can. Those are traits usually acquired through experience involving number of successes and mistakes in previous endeavors,… actually mostly through mistakes. I also believe that for some individuals those traits are more difficult to acquire than for others and it has nothing to do with them being less smart or less educated. It may have something to do with their personality types or maybe with their level of emotional intelligence (EQ). Can those be taught? Personality – NO. EQ – some believe that it can. In any case, I have trouble believing that Architect certifications can be useful as a measure of a skill of an Architect. But then again, maybe they are meant to signify something else. Maybe they are truly about taxonomy and mechanics and nothing else. Certification bodies seem to disagree, but then again, they do have a skin in the game. What do you think?