Blog post

Business Architecture is Part of Enterprise Architecture

By Philip Allega | August 30, 2010 | 10 Comments

Enterprise ArchitectureBusiness Architecture

A common misperception being hyped in EA circles concerns the notion that business architecture is something different from enterprise architecture. This is a blatant attempt to classify EA as something only applicable to IT when, in fact, EA is applicable to the ENTERPRISE that covers numerous viewpoints for stakeholders, including business, information, technology and solution architecture.

Where does this confusion come from?  To be blunt, the number of practitioners who have only used EA for IT, focusing upon the technology viewpoint of EA, have left a few large gaps in their approach to developing their EA viewpoint.  These gaps include:

  1. Developing a business contextthat guides the advice and deliverables within the technology architecture viewpoint, and all other viewpoints.
  2. Consuming the resulting advice within, minimally, the IT  investment decision-making process.
  3. Creating a governance and assurance mechanism that communicates the change that has occurred, or not occurred, in light of EA advice.

A common mistake we see is when well-meaning EA programs conflate the business architecture viewpoint of EA with the business context of EA.  The business context of EA is formed of:

  1. A vision of the future state.  At Gartner, we call this the Common Requirements Vision.  This deliverable is typically 10-12 pages and explicitly connects environmental trends, business strategies and requirements of business process and IT together in priority matrices.  This is a conceptual level document that requires confirmation of the target state, and its associated priorities, by the top of the governance decision-makers – typically, the people who decide how to allocate resources in the organization.
  2. A root, anchor model. The highest visualization of the enterprise, recognizable to the business, may be in the form of a business operating model, a hyper-extended view of the business ecosystem, business capability maps, a federated model or some combination of these for particular stakeholders.  All business processes, information, applications, solutions, technologies, people skills, people, other entities, are overlaid upon and disaggregated from this root, anchor, model.
  3. A set of guiding principles. These shape the investment and action behaviors of all those who seek to select, create, and implement anything within any EA viewpoint.

Unfortunately, some have conflated this business-context package with the work done in the business architecture viewpoint of EA.  These folks have mistakenly lured other EA practitioners into believing one or more of these myths:

  • I can continue to do technology architecture without having a business context
  • Business architecture is something completely separate from enterprise architecture.
  • EA is for IT only.

Mature practitioners lead EA programs that encompass all viewpoints of EA, informed by a business-context package.  They may focus more heavily upon one viewpoint or another, but they always link the interdependencies and interrelationships of these viewpoints in light of the business context over temporal states (past, current, near-transitional, future, optional future, retired future and more).

These leaders do not wait for the existence of a business architecture viewpoint to engage their EA advice in investment decision-making or wait to introduce assurance and governance into their EA processes.  Some pundits seem to believe that it’s only when business architecture is engaged that assurance and governance is possible.  This is, simply put, not true.

When I first ran across EA programs engaging in business architecture in the late 1990’s it was very early days.  10+ years later and we have more mature programs that understand and embrace this viewpoint of EA, but we also have, sadly, current practitioners who are not familiar with business architecture’s proper place in relation to an overall EA effort.

I am certain that this attempt to set the record straight will be controversial.  I hope that it encourages a dialogue of discovery and helps correct a hype filled market incorrectly placing business architecture outside EA.

Comments are closed

10 Comments

  • Dear Philip,

    It looks like the world you and I are in is still using architecture more with the focus on “arch” (power, ruling, so who is ruling over who) and still less focus on “tecton” (carpenter, so a professional craftsman). I practise architecture with the goal of the represented object in mind. So what should it do or what is it for, no matter how big or small it is. “It” is in our case a business that needs craftsmenship in every viewpoint of architecture making sure that this business’ goal is reached. What brings all architectural viewpoints together is the latter, business goal. What we need is a hype in craftsmenship and business leaders to prove a job well done by doing better business because of our provided better insight and source of better constructed business means.

    Maybe such a hype will provide businesses a bunch of professionals in architecture who are curious on how they can do this proven well done job instead of fighting over what to or not to use. The latter sounds like covering your … preparing for when it comes out the job is not well done. So proof of what to or not to use can only be found in doing better business. Let’s find that proof.

    Sorry for being so “emotional” on this important matter.

    Regards,

    Peter Ammerlaan

  • Tom Graves says:

    Philip – I strongly agree with you that business-architecture is a key component of enterprise-architecture, and that EA has and must have a much broader scope than IT-architecture alone.

    The IT-centric version of ‘enterprise architecture’ is actually a conflation or shorthand for the proper term, ‘enterprise-wide IT-architecture’. If we fail to recognise the conflation for what it is, then ‘business-architecture’ becomes a generalised grab-bag term for ‘anything not-IT that might impact on IT’ – which is essentially how business-architecture is (mis-)addressed in the major frameworks. (I won’t name any names here, but we all know which they are.)

    To be pedantic, enterprise-architecture has a significantly broader scope than the business itself: at times it must cover key links and transaction in the supply-chain, the market and even the overall socioeconomic milieu (government, communities etc) in which the business operates. To me, the business-architecture focusses primarily on the strategic level of the business, and should never be blurred into operational-level concerns such as process-architectures. The fact that most of the current IT-centric ‘EA’ frameworks do blur them together is a major source of architectural problems – especially in areas such as business-continuity and disaster-recovery-planning, where we cannot assume that the IT-systems will be operational or even exist any more.

    Probably the simplest way to put it is that old adage that “the business of business is business”: it’s that ‘business of the business’ that the business-architecture should cover. Everything else should be covered by some other sub-domain of architecture – process-architecture, security-architecture, skills-architecture, brand-architecture, information-architecture, physical-architecture, IT-infrastructure architecture and so on – all under the overall umbrella of the enterprise-architecture.

  • Jerry says:

    The Architectural Vision Is What Executives Need From Enterprise Architects

    Traditionally building architects have learned and communicated through the architectural vision. Selling this vision to clients became the method by which a building architect became recognized. In the early 20th century this consisted of examples, like Frank Lloyd Wrights mile high skyscraper, that would inspire public imagination. It would inspire professionals to become better architects. It would inspire the profession to reach for even greater heights.

    In enterprise architecture we occasionally have some of these visions. They are simple and direct, but inspire us. Different than the blueprints that are talked about within the current frameworks, the vision captures the essence of the architecture in a concise manner that is understood by enterprise architects and their clients. It includes the reasoning for design choices. It is framed within the context of business through and understanding of its link through the operational model.

    Businessmen are experts in seeing value. They will always talk about their return on investment, cost control, and revenue. Only those in business understand that this is just the metrics for the game. What businessmen really thrive on is perception. This is why business is so interested in enterprise architecture. The metrics they will justify and figure out. The architectural vision is what they need enterprise architects for!

    We as professional enterprise architects seek to create understanding, develop a common thought space and, change hearts and minds. To that end, this site is not about collecting design diagrams but rather those architectural visions, stakeholder communication, and decision support artifacts that not only enable enterprise architects to be successful but will change the way people think about enterprise architecture, including core capabilities of business architects and enterprise architects.

    Business Architects:
    – Organizational Context – Impacting the formal structure, work management practices, human resource policies, leadership, and culture
    – Corporate Vision – Mapping and alignment with the mission, objectives, goals, tactics, and strategies
    – Value Chains – Strengthening alliances, capabilities, services, and processes by determining the return on technology investments.
    – Plan – Rationalizing roadmap investments with respect to capabilities, resources, and competencies
    – Marketplace – Recognizing internal and external competitive forces that determine the product/service offerings and their relationship
    – Language – Defining the glossary, taxonomies, concepts, patterns, and references used to frame the organization

    Enterprise Architects:
    – Aligning strategic and operational views of business
    – Driving the technology vision
    – Transforming and automating operations
    – Facilitating and governing organizational change
    – Mitigating risk
    – Overseeing investments
    – Managing the architecture
    – Integrating people, processes, and technology

  • Roger Griessen says:

    Philip – I couldn’t agree more on the statement you make in your article’s title.

    However, I also see (and understand) that quite some confusion is around about this specifc point.

    Reading and hearing lots about how important the “business viewpoint” is, to me it looks like many experienced EA practitioners today find themselves asking “So how do I fit this business viewpoint INTO my EA?”. Maybe this is the wrong question to ask.

    Interpreting a bit on your explanation of the “origins of confusion” I’d suggest the following to every EA practitioner (or craftsman, I agree also with Peter’s comment) who has gotten stuck with this point: Ask yourself, which aspects (views) within the business viewpoint could do good and/or useful things FOR your EA (approach).

    I’m working for a federal government in a European country. We are about to define a “context-logic”, to systematically derive and document a “business context”, then a particular “architecture context” to tackle architectural work within this “business context”. The “architecture context” when blended with “goals” or “guiding principles”, sort of produces (“architected”) “solution contexts” — or, for purely technical matters, (predefined) system contexts.

    We found, that this helps in our environment. Especially as in governent, it’s sometimes not that evident how to capture “business context”.

    To conclude: The only “business viewpoint architectural model” we developed by now is what you call the “root/anchor model” — we anchor “business context” using the elements of that model. That will be the only “business architecture deliverable” we are going to have for quite some time — simply because our primary aim, or our “EA engagement model” (maybe another question to ask about) is not about “business transformation” (as in some other goverments), but is all about “business/IT alignment”.

  • Philip Allega says:

    Thanks, Jerry, for your feedback. I think I’d probably quibble about role delineation, but I think we’re sympatico when it comes to your ruminations concerning the similiarities of building and enterprise architects. I talked about that, a litlte, in this blog: https://blogs.gartner.com/philip-allega/2010/08/19/tour-by-architects-lessons-for-enterprise-architecture/.

    I appreciate your comments.

    Philip

  • Philip Allega says:

    Thanks, Tom. I, too, recall the days of transition for EWITA to EA. The applicability of EA to many disciplines, processes, endeavors, and more just makes them richer. I agree that the conflation is problematic; hence, my blog and a number of research papers for Gartner clients. Still, this conflation has had a lot of hype that hasn’t quite dissipated.

    All viewpoints of EA should deal with the strategic, future state. Unfortunately, blurring into operational aspects occurs due to common issues:

    * Too few people to divide roles accordingly
    * Groups who do not understand how to set the dividing line
    * Cultures that reward people for being on the big project

    I’m certain there are more, but these came to me easily. I will, however, concede that there’s been some complicity on the part of various proponents of EA approaches/frameworks because they have not brought clarity to this dividing line either.

    Lastly, I think that your reminder that “the business of business is business” is not just good for those who focus upon business architecture but also for those who focus upon the technology architecture viewpoint of EA. In “The Real Business of IT“, Richard Hunter and George Westerman note that the first step on the value path is, and I’m paraphrasing here, to put all technology terms in the context of the business. Therefore, we’re not talking about network uptime in a retail organization we’re talking about POS availabiliity at critical and non-critical day-parts. We’re not talking about the ERP system, we’re talking about supply chain management.

    That’s a small step, but an important distinction that the authors note eludes the majority of IT professionals. This inability to cross that Rubicon/Paradigm exacerbates those proponents of business architecture as something separate from EA.

  • Philip Allega says:

    Peter,

    I appreciate your passion for this topic. Execution on business value outcomes based upon commitments are, indeed, challenging. As the weather begins to turn in the Northern Hemisphere, the Scotsmen Robert Burns comes to mind:

    But little Mouse, you are not alone,
    In proving foresight may be vain:
    The best laid schemes of mice and men
    Go often askew
    ,
    And leave us nothing but grief and pain,
    For promised joy!

    I added the emphasis on the “…best laid schemes…” portion.

    Crafting every viewpoint of EA in order to deliver business value is, indeed, a loft and correct goal. As I noted in my comments to Tom Graves, there are good examples of success that are worth noting, but the few that have “crossed the Rubicon” (note: English idiom referring to crossing the point of no return in reference to Julius Caesar’s crossing of that River of the same name in 49 BC as he marched on to Rome) to define IT in business value terms. That said, to paraphrase the 1st step for various recovery programs, admitting that there’s a problem and our lives our umanageable as a result is a step in the right direction.

    Philip

  • Cliff Berg says:

    I think the comments here are excellent and I agree with all of them. I also think that Philip is right that the “root” or “anchor model” should be “the highest visualization of the enterprise, recognizable to the business, may be in the form of a business operating model, a hyper-extended view of the business ecosystem….” The future state is then a vision of what must change in order to capture the opportunities that are apparent.

    I personally resist the notion that there are many different “architectures” that must be synthesized. I don’t like to put issues into predefined categories; and I also think that if you create job descriptions for things like “security architecture”, “business architecture”, “IT architecture”, and the like then those professionals start creating documents for those sets of issues, resulting in silos of thought.

    I much prefer to think that there is one “architecture” for what the business wants to do, and it is the synthesis of the “root model” and the “future state”, as Philip puts it. The analysis that goes into the future state must have input from experts from security, business, IT, and all other areas that are impacted. These experts are not architects, by definition, because they focus on a particular set of issues, and not on the business-wide synthesis of those issues.

    To me, the most useful role of an enterprise architect is to serve as an analyst who analyzes and synthesizes the various issues that impact the future state, and presents that analysis to decision-makers. The decision-makers then decide. To perform this synthesis, the EA must have a strong grasp of all of the relevant issues, from business to technology and whatever else is important.

  • Philip Allega says:

    Thanks, Cliff. Your post makes me think about the conflict between the work that is done and the roles that execute that role. It’s a common conflation and attempts to definitively divide such roles are challenging, to be fair. That said, understanding the factors that assign and divide such roles under varying conditions warrants conversations particular to an organizations political and cultural conditiions.

    Philip

  • Philip Allega says:

    Thanks, Jerry. Your points remind me that there’s more to respond to concerning the allocation of the role versus the execution of the process. I’m putting that on my work list.

    Philip