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.

 

What do Architects do?

What do architects do? Here is another attempt at explaining by Tom Graves/Tetradian. Why is it that I always feel that I have to explain what EA does. The discipline that every organization needs, every organization says it wants, and every organization questions. Read on.

What do architects do? And why? At this point we’d usually reach out for some apposite metaphor… And yes, by far the most common metaphor is ‘boxes and lines’, or ‘boxes and arrows’. If we take the most stereotyped, ‘boxy’ view of the organisation: …then what architects would typically do is to populate the details of…

via Architecture as boxes, lines and glue — Tom Graves / Tetradian

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.

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?

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.

Surviving Enterprise Models – breadth over depth

It was with great interest that I read Nick Malik’s post “What makes models interesting“. In his post, Nick speaks about his EBMM model but the fundamental concepts of approaching modeling and the questions it poses are more universal and applicable to all kinds of enterprise modeling. Whether it is EBMM, ArchiMate, UML, or any other “notation du jour” there is always that temptation to add more to the model. I think it is human nature. After we model something with a given standard, we become familiar with the contents of the model and over time it starts to feel as too obvious to be useful. This in turn leads to temptation to “improve” it. Sometimes improvements are warranted and sometimes they aren’t. If they are driven by desire to answer some specific questions that contribute to enterprise value, then great, but if they are driven primarily by model purity or general quest for more detail then you may be well advised to take a pause. We don’t want to model just for the sake of modeling. Instead, we want to use the models for strategic and tactical planning, for architecture alignment across the enterprise, for optimization of operations etc. Just to be sure, I’m talking about enterprise models here. Models that aim to illustrate where the enterprise is and where the enterprise is going. Those who have been exposed to enterprise architecture at a large organization know what I’m talking about. They also know how challenging that is. The reason I’m making that distinction is because when dealing with models that describe specific solution you may want to get to whatever level of detail is appropriate to explain the solution to your audience. If you try the same for the enterprise-level models you may find that it is extremely difficult to tie everything together.

I know that some will question the wisdom of even having the enterprise-wide models and will tell me that I am better off to focus on a specific area or on a specific problem. Well, in the end it all comes down to what questions I am trying to answer doesn’t it? So back to the questions… The questions that we ask at the enterprise level are different from questions asked during implementation of a solution. Some of the enterprise-level questions may be:

  • Where are the undesirable system redundancies?
  • What systems rely on non-standard technology?
  • Which systems cost more to operate?
  • Which critical business processes are supported by high availability applications/services?

Some of the solution-level questions may be:

  • What type of interface is used to access a service?
  • Is service consumed synchronously or asynchronously?
  • What components are used to build an application?

All good questions, but not all of them can or should be answered with the same model. In other words, models have to be fit for purpose. Attempts to mix different concerns usually end in a mess. …And then there is this pesky law of diminishing returns. How much work do we want to put into the upkeep of the models? More detail means every time that detail changes the model should be updated, right? Now take that to the scale of a large enterprise with many system inter-dependencies and it translates into a massive amount of work. Detection of those changes alone is a challenge too because in a large enterprise change tends to be constant and occur in many places at the same time.

If we assume that the architects are the keepers of the models, we need to ask ourselves how much of their time should be spent on keeping the models useful. Useful models should be current and given the breadth and rate of change it implies a significant effort. It seems that architect’s time would be better spent on model driven analysis and planning (a.k.a. architecting). Otherwise, we are approaching the territory of modeling for the sake of modeling, where we devote most of the energy to maintaining the models and not having time to actually use them.

So what practical advice can we employ for enterprise-level modeling? Here are my suggestions:

  1. Ask yourself what questions are you trying to answer with the model and prioritize them. Set out to build models for a few high-priority questions first.
  2. Establish a set of modeling rules that you can apply on top of your favorite modeling notation. This approach will keep you at the consistent level and promote discipline needed to build enterprise-wide models incrementally.
  3. Resist putting more detail into models at least until you can be sure what it takes to maintain them at the current level.
  4. Keep verifying that  the models help you answer the questions for which they were built and adjust accordingly.
  5. Rinse and repeat, starting with step 1.

Happy modeling!

Business Architecture Rising at BBC

Recently, I attended the Building Business Capability (BBC) conference in Las Vegas. I was tempted mainly by the Business Architecture track as I was curious to learn more about the current state of affairs in that field. Here are some of my observations, and conclusions after attending the event.

  • Confusion about Enterprise Architecture and its scope is further magnified by more confusion around Business Architecture. Various speakers made different pronouncements about the relationship between the two. Most saw Business Architecture as a component of Enterprise Architecture but some attempted to present Enterprise Architecture as being about IT and Business Architecture being about business. Another speaker suggested that Business Architecture overlaps with Enterprise Architecture but still is a distinct discipline that must “interface” with the Enterprise Architecture.
    I agree with the majority that sees Business Architecture as a component of Enterprise Architecture. As to other views, well…, I find it fascinating that some people need to complicate things. Of course, Enterprise Architecture is about the enterprise, and the enterprise is about business, DUH! Need we say more? Presenting Business Architecture as something separate from Enterprise Architecture only increases confusion and…just wait, will lead to more frameworks. God knows we don’t need any more architecture frameworks. If you insist, then let’s fix the ones we have by giving them more business focus (…looking at you TOGAF…) instead of inventing new ones. In any case, enough with inventing more distinct “architectures”.
  • Traditional roles of Business Analysts and Architects are evolving. Both roles are pushed to pay more attention to business value and business differentiation. Currently, in most organizations Business Analysts are relegated to requirement gatherers for IT projects. Their main focus is to translate requirements received from business into specific definition of IT deliverables and to perform validation of those requirements upon completion of implementation. There is very little going on there in regard to actual business analysis, not to mention Business Architecture. As Business Architecture rises to more prominence, Business Analysts must assume a role of true analysts and partner with Enterprise Architects in a comprehensive approach to Enterprise Architecture. At the same time Enterprise Architects are pushed to reach out to business and expand their role in the Business Architecture realm to make Enterprise Architecture more business-centric and thus more relevant to generating business value. This will likely lead to interesting dynamic with career paths. Both Business Analysts and Enterprise Architects are told that being Business Architects  is in their future. However, Enterprise Architects also consider themselves well versed in technology, while Business Analysts not necessarily so. So where does this leave us? Will Enterprise Architects become generalists who rely on Business Architects, specialists, for the Business Architecture part of Enterprise Architecture? Or perhaps Enterprise Architecture  will be pushed back to being again only about IT and Business Architects from Business Analyst ranks will direct Enterprise Architects how to shape the IT side of the enterprise?
  • Business Capabilities emerge as the way to provide a common taxonomy that can bridge the gap between business and technology. Capabilities allow architects to focus on “what” rather than “how”. They provide an anchor to relate systems and their underlying technologies to the business context, which includes organization, people and processes. Furthermore, they help break the silos, ever prevalent in larger organizations, which often represent the obstacle to effective Enterprise Architecture.
    Some can argue that capabilities and capability models have been around for a while and there is nothing new here. For me, the new thing was the evidence that companies start registering real successes with capability approach to Enterprise Architecture. It seems that capability models are finally taking off, coincidentally  at the time when Enterprise Architecture, after some soul-searching, is beginning to focus on business value.

Overall, BBC was an interesting conference. Not great, just good. I found that too many speakers were contradicting each other, but truth be told they were simply expressing their own opinions and there is nothing wrong with that. I suspect that the conference was of most value to Business Analysts especially with several BA-oriented tracks. Business Architecture track was messy but it is probably due to the fact that most of us still try to wrap our minds around how it fits with everything else. 🙂 I will consider attending next year, if only to watch the further evolution of the Business Architecture concepts.

After the love is gone…

Interesting observation published by Forbes: “CIOs And Cloud Computing: How IT Can Get Back In The Driver’s Seat“. While the article appears to apply to management of infrastructure in the world of cloud computing, it is symptomatic of a larger trend.

We have heard of the looming demise of IT for some time now. It started with outsourcing and globalization and intensified with the advent of cloud computing. The trend of “lost love” between Business and IT and illustrated in this article is not uncommon. I think it stems from factors like these:

  • Business sees IT as an inhibitor rather than enabler of achieving business goals faster. The technical debt accumulated over the years starts to demand the interest payments. Delivery takes longer because complexity was not dealt with on ongoing basis. Desperate IT departments try to please the Business and they cut corners, leading to more technical debt. The vicious circle continues.
  • Business sees IT as cost, which ever increases without generating more value. It’s like dealing with a cable TV company. The bill gets bigger every six months but the programming remains the same or gets worse.
  • Business believes they can do IT themselves. Why wouldn’t they? Anyone can build a web site (okay, okay, maybe with the exception of the US government), anyone can buy cloud storage, anyone can write an app or commission writing one for pennies… Of course it is not that simple, but many on the Business side believe it is and droves of cloud service  providers do their best to reinforce that belief.

Having IT relinquish some of its Implementation role in favor of the Advisory role is a good advice. Easier said than done though. It’s like with human relationships. After the love is gone it’s hard to get the flame going again. Is Business predisposed to seek advice from its IT Department, especially when there are so many advisers out there, who are eager to say “yes” to every request? Let’s hope so… This is where the Enterprise Architecture (EA) can lead. Stop talking to Business about interfaces, gigabits, servers, and tools. Instead, start talking about total cost of ownership, speed to market, competitive advantage, quality etc. In other words, speak the language of Business, not the language of IT. But more importantly, don’t just speak that language but start thinking that way too. Business really doesn’t care how IT is done anymore. They want us geeks to figure it out and not to bother them. For us however, it is a matter of survival. In order to serve Business better we must understand what it wants, or… fade into oblivion. We can only understand it if we think like business people.

So yes, again, it is all about the business. Adapt or prepare for extinction!