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.

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 BCC

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.