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.

 

Architecture value and the KISS principle

It seems that everywhere I turn, somebody talks about the business value of architecture. People talk about it but few found a good way to measure it and to communicate it. From what I could gather, most attempts at formalizing valuation techniques for architecture take a process-heavy, formulaic approach that claims to produce a score that identifies the “best” architecture. Most of those attempts fail at that too because they forget to recognize that we as architects are usually not the ones that make architectural decisions. As shocking as it sounds, I wonder how many of us architects actually hold a bag of money to fund the implementation of the best architecture possible? I’m guessing that not too many of us have that luxury. In reality, architecture is the art of compromise where business holds the purse and architects recommend and try to influence the best architectural outcomes. It is another way of saying that architecture decisions are rarely made solely on the technical merits of architecture. Instead, they are made as a result of many technical and non-technical considerations, with those non-technical ones often being out of the sphere of influence of architects. In this light, it seems that an architecture valuation technique may be most useful if it fosters meaningful discussion with business and if it presents business-themed choices rather than singular, techno-centric recommendation.

The role of architecture is to guide the change of a system.  In absence of change, architecture is not needed. You just build something and it remains – no need to move it, no need to extend it, no need to optimize it, no need to make it work in a new context. In reality, change is ubiquitous and architecture as a planning discipline is called upon to enable and guide transition from one state to another. In a way, architecture is a little bit like a GPS device in your car. It helps you get from your current location to your desired destination. Think about it… You turn it on and it acquires the satellite signal and determines your current location. It needs to know where you are in order to plot the course for you. Then you punch in your destination and the device computes the optimal path to get there. As it computes it, it considers your preferences that you have pre-recorded in your device. Do  you want the fastest route or the shortest route? Do you want to  avoid toll roads? Do you want a scenic route?
What are those decisions if not value-based preferences? Cheap or fast? Simple or flexible? In the end almost every decision we make includes this underlying tradeoff analysis. Sometimes it is done in the open and sometimes it is done subconsciously based on our preconceived notions of value.

Trouble with architecture is that its value is often difficult to express. In most cases, good architecture will provide benefits in the long run but be perceived as expense in the near term. This is different from the functional aspects of a system. When the system is tasked  with delivering new or enhanced functionality, it is expected that there will be cost and time associated with implementation. The purse-holding stakeholders expect it and they also expect that the benefits of that new functionality will start coming to fruition soon after the new functionality is put into operation. It is trickier with architecture. Architecture of a system is usually hidden, and does not often manifest itself in flashy screens or availability of functions. More so, its greatest benefits often come into play not right after deployment, but down the road, when it’s time to extend it or integrate it with other systems. Those long-term considerations can be very elusive, especially to business stakeholders who may have trouble understanding them, especially when they are discussed in a manner that makes every non-techie’s eyes roll. Hey, business person! Do you want to talk about system’s scalability, deployability or utilization?!

Business people want to talk about business things, like time or money. They like to know what architecture means to time and money but are not necessarily interested in all the ugly details. Talking to business people in a traditional language of architecture may be responsible for architecture not being fully appreciated and consequently neglected or even ignored. It is not practical to expect business people to adopt the language of architecture. Instead, it is the architects who must arm themselves in the vernacular that allows effective communication of architecture tradeoffs and how those tradeoffs affect the value proposition of the system.

One way to approach it is to express value through a small set of attributes that encompass business and architectural considerations in a way that is palatable by non-technical people. Each attribute can then be scored individually on a predefined scale, say zero to four, with four being the most desirable and zero being the least desirable. Each architecture choice can then be described through the set of those scored attributes giving stakeholders a reasonable idea of the trade-offs between different choices.

For example, if we are looking for ways to architect a new system, we may be faced with the following choices:

  • Build – build it in-house and host it on premises.
  • Buy – buy a commercial, off-the-shelf product as the basis of the new system and host it on premises.
  • Rent – contract the SaaS solution as the basis of the new system.

Each one of those choices will have a different architecture that can be summarized through the set of attributes in a way that will illuminate the key differences.

Consider grouping those attributes in three categories: Cost, Speed, and Architecture Quality. The first two categories group attributes that should be most familiar to business as they deal with the money and time aspects of the system. The third category is more typical for architecture discussions and groups attributes that deal with the long-term technical aspects of the system.

The first category is Cost. Here we can use three attributes that look at the cost from different perspectives:

  • Implementation Cost includes all labor and capital cost that has to be incurred in order to deliver the proposed system. The lowest implementation cost is most desirable.
  • Operating Cost includes all costs, labor and capital required to maintain and support the proposed system once it is put into production. Operating cost can be expressed as an annual, or multi-year expenditure, depending on your organization’s preferences. The lowest operation cost is preferred.
  • Savings on Future Solutions includes predicted savings that can be realized down the road as a consequence of the proposed architecture. This is different from the implementation cost or operating cost of the proposed system. It is a long-term measure of savings in the future implementation costs. For example, imagine that the proposed architecture established Web API management solution for the enterprise. It carries implementation cost and operating cost. However its real cost-related benefit lies in the ability to develop applications cheaper down the road. The highest level of savings is desirable.

The second category is Speed. Here we can use two attributes that look at the time from different perspectives:

  • Time to Benefit reflects the estimate of how soon the system can begin generating business benefits. Of course, the sooner the better.
  • Enabled Speed of Solutions reflects predicted gains in speed of delivery down the road as a consequence of the proposed architecture. Just like Savings on future solution in the Cost category, this attribute is a long-term measure that is focused on the ability to deliver future solutions faster.

The third category is Architecture Quality. Here we can use four attributes that somewhat resemble quality attributes well-known in the system engineering world. The difference is that our attributes are more high-level and represent amalgamation of more detailed ones. The amalgamation is necessary in order to convey characteristics of an architecture in a way that is more palatable to business stakeholders. Another reason is to reduce the number of quality attributes to the level that is manageable, easily presentable and less overwhelming. The attributes in the Architecture Quality category can be the following, with higher score generally preferable for all attributes:

  • Security is the ability of the proposed system to prevent malicious or accidental actions outside of the designed usage, and to prevent disclosure or loss of information.
  • Performance is the cumulative measure of manageability, throughput and latency. It measures the effectiveness of the proposed system.
  • Availability is the cumulative measure of downtime, capacity, utilization and recoverability. It is an expression of run-time characteristics of the system.
  • Flexibility is the cumulative measure of maintainability, scalability, reusability, and testability. It is an expression of design and build characteristics of the proposed system.

Given the attributes defined above, we conduct the analysis of our example choices (Build, Buy, Rent) and score each attribute on the scale of zero to four. Next, we plot he results on a radar chart.

Radar

As you can see, each option has a slightly different value proposition. In our example, the Rent option seems most attractive from the perspective of all cost attributes. The Build option is the most attractive from the flexibility standpoint. Perhaps it is because that option allows us to tailor the system exactly to our needs. Build option seems to be the most attractive from the perspective of the enabling the speed of future solutions too. Why is that? Of course, you can’t tell from the diagram, but whoever scored it so high must have  had some justification for it. That justification better be recorded somewhere to justify this score.

This perfectly illustrates the key benefits and shortcomings of this approach. Foremost, this approach serves as a communication tool, which intends to generate meaningful conversations about architecture. It doesn’t provide all answers but it certainly allows quick identification of meaningful trade-offs. Stakeholders will agree with some of the scores and challenge the others. They will certainly ask for explanations. In the end, the decisions will consider, or at minimum acknowledge, the architecture trade-offs and the long-term value proposition behind them. Degree to which the long-term attributes influence that decision will vary but at least the decision will be overt about accepting or ignoring architecture concerns. This is great! At least we are talking about architecture, and not just among ourselves, architects!

There is something more to be said about the attributes. While the attributes in the Cost and Speed categories are fairly obvious and usually easily accepted by the audience, the Architecture Quality attributes may be somewhat controversial, especially for architects. After all, the arbitrarily selected four attributes obscure more detailed characteristics of the system and may be misleading. Also, in some cases one detailed characteristic may balance out another, which would lead to rolled-up neutral assessment of the attribute. Yes, this is all true. However, consider the following:

  • Discussion about detailed characteristics of architecture (quality attributes) can still occur. In fact, good analysis should occur at that level and the record of that analysis kept. Results, however, can be rolled up to foster better engagement of business in trade-off conversations.
  • Some detailed characteristics of architecture are probably more significant than others in your organization. Check what drove good and bad architectures in the past and you may  find that not all quality attributes are equally important. Perhaps it is not the ones described above. Find your own set.
  • All quality attributes are important, but discussion about most of them will make your business partners roll their eyes. They don’t have the  patience or technical aptitude to debate merits of each one. They want “executive summary” with details available only when needed.
  • English (or any other natural language for that matter) is the language we communicate with business, not architect-speak. Speaking about system availability is more natural than speaking about utilization or failure transparency. Speaking about flexibility is more natural than speaking about deployability or testability.

There is something to be said about the representation of the value of architectural choices. For our example, we chose the radar chart. It is not very innovative in itself, but it is simple and easily recognizable at the first glance. Just by quickly looking at it we can get an idea of what the trade-offs are. Again, think about the audience who would be well served by something readily recognizable and easy to decipher. With some luck, consistent presentation of the architecture trade-offs will get so ingrained in business stakeholders’ memory that they will be asking to see the architecture value chart themselves.

The approach described in this post is not a complete methodology. It is a way to categorize, score and communicate value but it doesn’t make any assumptions about who does it and how. It is expected that this method could be embedded within the established architecture process in your organization and tailored to consider unique organizational and cultural aspects of your company. We have successfully implemented this method in my workplace and chances are it may work for you too. If there is one thing that I could point to as a singular factor in success of this method is its conscious and strict adherence to the K.I.S.S. principle (Keep it Simple, Stupid). Of course there are some nuances of this method that I didn’t get into here, but I would be happy to discuss if you are interested.  Please drop me a note if you have questions.

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!

Six heresies for enterprise architecture

Voytek Janisz:

Excellent post, which further reinforces my beliefs that architecture frameworks are way oversold. Iterative, value-based approach to EA, without religious devotion to a given framework is what I have been preaching too. Great post Kailash!

Originally posted on Eight to Late:

Introduction

In a recent article in Forbes, Jason Bloomberg asks if Enterprise Architecture (EA) is “completely broken”.  He reckons it is, and that EA frameworks, such as TOGAF and the Zachman Framework, are at least partly to blame.  Here’s what he has to say about frameworks:

EA generally centers on the use of a framework like The Open Group Architecture Framework (TOGAF), the Zachman Framework™, or one of a handful of others. Yet while the use of such frameworks can successfully lead to business value, [they] tend to become self-referential… that [Enterprise Architects end up] spending all their effort working with the framework instead of solving real problems.

From experience, I’d have to agree: many architects are so absorbed by frameworks that they overlook their prime imperative, which is to deliver tangible value rather than pretty diagrams.

In this post I present six (possibly heretical!) practices that underpin an

View original 1,220 more words

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.

“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?

The Myth of Collaboration

Originally posted on Petervan:

Rogier Noort  just published a post on his site, for a great part based on an interview he did with me during the Enterprise 2.0 Summit in Paris in February of this year. Rogier’s original title of the post was “Collaboration:  Salvation or Myth”. It’s a great post, and Rogier clearly took the pain to reflect on our conversation. I would label it as “The Myth of Collaboration”. Some people call my point of view blasphemy in a period where everything has to be “social”, “working together” and “collaboration and hacking spaces”. So be it. I just felt there was something deep wrong about it, and Rogier did an awesome job of articulating my thoughts. I have copied the text in it’s entirety, and just added the usual colour emphasis.

+++ Start Rogier’s post +++

Collaboration is an important part of productivity. It’s a highly desired commodity, but seemingly more…

View original 1,090 more words

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.

Aside

I will be speaking about the practical approach to integrating enterprise architecture at the SATURN 2014 conference in Portland, OR. Abstract below.

Integrating Enterprise Architecture

In the era when contributing to business value is the principal consideration of IT, large and distributed organizations face a challenge of understanding how their capabilities are realized and how they can synchronously evolve them in alignment with business strategy. Structured information coupled with efficient architecture processes sets the foundation by addressing several issues: 

  • Complex interdependent systems that evolved independently increase technical debt. 
  • Nonexistent, inconsistent, or scattered architecture descriptions make planning difficult and extend the delivery time of solutions. 
  • Unclear dependencies of business capabilities on technology lead to weak commitment to business goals. 

The TOGAF, ArchiMate, and Sparx EA tools are cornerstones of Progressive’s approach to integrated enterprise architecture. By leveraging existing systems-development life-cycle processes and architecture-governance structures, Progressive implemented elements of the TOGAF Architecture Development Method and established consistency in defining and reviewing target architectures. Investing in modeling skills and introducing standard building blocks for architecture models allow architects to describe the systems and capabilities in a uniform way that produces an overall view of the current and future states of the enterprise. This presentation presents a practical approach to implementing integrated enterprise architecture at a large organization. Specific tools, frameworks, and languages serve only as a context for this experience-based story.

It’s a Journey – Don’t stop believing.

Aside

Not sure if I should be depressed or relieved after reading the The Enterprise Architecture Paradox. On one hand it smacks of futility of EA efforts and illustrates the frustrations of EA work, on the other it proves that we are not alone in our “journey”. For the time being we need to keep pushing and continue to realize those invisible wins. Don’t Stop Believing! Worth reading.