Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

May, 2012

  • Inside Architecture

    Three Schools of Thought for Enterprise Architecture


    It is interesting to watch the debates online between the different schools of thought of Enterprise Architecture.  The discussion was started by James Lapalme, who published a paper on "three schools of thought" which is in pre-print for the IEEE's IT Professional journal.  (citation)  Mostly the online discussion focused around the role of the newest domain of Enterprise Architecture… the domain of Business Architecture.  Depending on how Business Architecture is understood, the role of EA can be dramatically different.

    • Some say that EA is about improving IT. In the diagram below, this is “Enterprise IT Architecting.”  In the online groups, we call this EITA.   In this model, EA is a mechanism for designing IT services and creating IT systems that address enterprise needs. It’s just a bare step above Enterprise Application Architecture by operating outside the constraints of funded projects, but the impact occurs in IT.  For this first group, Business Architecture is just another name for Business Analysis.
    • Others say EA is about aligning the business with all of its capabilities, including IT. For these folks, Business Architecture exists, but it’s primary impact is internal. Business Architects insure that the right initiatives are created in order to achieve business strategy. In the diagram below, this is labeled “Enterprise Integrating.”  In this school of thought, Business Architecture doesn’t really impact business strategy. Business Architecture uses capability analysis to understand the impacts of strategy on the business processes and systems, and helps to frame the initiatives that should be created. Only after the initiatives are started would a business analyst even get involved. In this model, EA provides all the benefits of the first group, AND insures that investments are made in the right place.
    • A third group say that EA is about Enterprise Ecological Adaptation. For these folks, Business Architects help analyze the movements of the market, and work closely with business leaders to develop strategies based on the capabilities and positioning of the company that are likely to generate new revenue, improve market position, improve customer loyalty, and reduce costs.  EA and Business Architecture help the business adapt to the ecosystem in which it exists.  In this model, EA provides all the benefits of the first two groups, AND insures that the business responds to the market conditions in a logical manner.  For some in this camp, Business Architects are not even part of EA.

    Depending on the company your work in, there’s a case to be made for each. Personally, I prefer to think of EA as alignment at the minimum, and strategic effectiveness as an ideal state.  I created the following image to illustrate these distinctions.  For further reference, please read James Lapalme's paper in the IEEE IT Professional journal.


  • Inside Architecture

    Setting Up A New EA or BA Practice


    Recently, I was contacted via this blog by an individual who had been challenged to set up a new Business Architecture practice within his company’s Enterprise Architecture team.  He reached out to me to ask about some books to read and some advice.  I’m expanding my message to him here.  As always, I’d love to hear your comments and feedback. 


    You have quite a challenge ahead of you.  While it may seem obvious, there are some steps that you need to do first.  You have to essentially manage the change that you are bringing to your own organization.


    1. Value Proposition: Get together with your sponsor and create your charter.  This is critical to having a clear goal that you will achieve, and clear measures by which you will achieve them.  I cannot underestimate the importance of this step.  Do not skip. 
    2. Engagement Model: Create a clear and simple process for deciding what your team will focus on and how you will find the right opportunities to attack.  This is your engagement model.  Formalize it, and stick to it.  You will be pulled in every direction.  Clear simple criteria is your only defense against being scattered to the wind.
    3. Clearly define your service: what deliverables will be produced, and which individual stakeholders are going to be expected to use those deliverables, at what time, to what end. 
    4. Stakeholder buy-in: With the help of your sponsor, meet one on one with each of these key stakeholders and make sure that they understand your value proposition, resources, and process impacts.  You may be changing the lives of some key people.  Get their buy-in. Be prepared to rewrite the value proposition.  The value you deliver must be tied to the needs that they express.
    5. Scorecard: Hold yourselves accountable.  Create a scorecard and use it with your team to demonstrate how progress should occur, and use it with your leaders to show how value has been delivered. 
    6. Staff Training: Send everyone to a training class in Business Architecture… not so that they are all educated, but so that everyone is educated on the same terms, artifacts, and processes.  This is the most difficult one to offer advice on because I have not yet found many good options… then again, we have an internal team that has answered the call, so I have not lately looked.  Perhaps good options exist. 


    As far as required reading… specific to the BA practice challenge

    The list below is intentionally short.  I feel that every member of the team should read each of these books.  I placed them in order of usefulness for your task at hand (preparing the staff of a new BA function within an EA team).  All are very valuable… but being higher on the list means that I consider the book to be more valuable, sooner, than the ones below.


    • “Business Architecture: The Art and Practice of Business Transformation” by Neil McWhorter and William Ulrich
    • “Crossing the Chasm” by Geoffrey Moore
    • “How to Measure Anything” by Douglas Hubbard
    • “Enterprise Architecture as Strategy” Jeanne Ross and Peter Weill
    • “Competitive Advantage” and “Competitive Strategy” by Michael Porter
    • “Make It Stick” and “Switch” by Chip and Dan Heath


    For the team manager, one more book to be read concurrently with the ones above:

    • "Business Architecture: An Emerging Profession." Paul A. Bodine and Jack Hilty



    OK… I have probably just angered some of my friends, because I didn’t include all of their books or reference materials in my short list.  Please, before you flame me, realize that this response is to a specific individual with a specific problem.  The EA team existed, but didn’t have a BA function… what does that tell you?  That it is an EITA team, in all likelihood.  Is every possible book or resource appropriate for that situation?  Probably not.  So I selected a small set of valuable books.  There are many more out there.

  • Inside Architecture

    EA Certifications Distilled


    Mike Walker, one of my colleagues here at Microsoft, has done an excellent job of distilling various options for EA certification.  He made this presentation at the most recent Open Group Conference.  Strong Recommend.

  • Inside Architecture

    On the road to a Business Architecture Manifesto


    One very powerful metaphor that has reverberated throughout the technical community, in the past few years, was the Agile Manifesto.  Created by a group of folks who wanted to communicate the principles that drove their thinking, the Agile Manifesto has been a very useful tool for deciding if a particular practice is being done well.  I think it may be time to build one for the Business Architecture space.

    That said, I am by myself, sitting in my living room.  I am in no position to speak for the community of business architects.  So, this submission is a suggestion for content that could be useful when the conversation begins.  It is my personal opinion about the principles of business architecture.  I would hope to bring this material to a group of other BA practitioners, as my contribution, to develop a full consensus on business architecture manifesto.  

    First off, in order to develop principles for business architecture, we need to describe the problem that we are trying to solve. 

    The problem that business architecture solves

    Business architecture is a relatively new field that addresses an old problem.  Most business people recognize the underlying truth: the structure and practices of your organization directly impacts your ability to deliver the intended value.  Whether we are talking about a military service, a civilian government agency, a non-profit organization, or a for-profit business, the structures and processes that a leader chooses to employ will impact the results that the organization will produce.  That includes both intended and unintended results.  So the basic problem is this: how do we deliver on our mission while maintaining our values?

    Business architecture gets to deal with a slice of that problem.  As people, we need to organize around a common shared mission.  We need to know what we want, and we need to go get it.  Humans can be pretty haphazard.  Business architecture does not address every issue.  Business architecture attempts to answer this question: what is the optimal way to organize?  Business architecture typically does NOT answer questions around the integration of corporate controls, or supporting activities like how to find staff to fill new roles.  Business architecture is focused on the narrow slice of “how to organize.” 

    So why do we need business architecture to solve this problem?  There are literally hundreds of good, well researched, books that offer useful insight for solving this problem.  Why use a business architecture approach?  Because BA brings a novel approach, one based on the rigorous application of conceptual traceability, process improvement, information science, and mathematics.  While most of the business analysis methods prior to business architecture were founded, fundamentally, in social science, mechanical engineering, and even education, business architecture focuses on the newer sciences that have emerged in the computerized age. 

    How does business architecture solve the problem

    Business architecture’s unique value proposition is to focus on answering the questions of business structural and organizational effectiveness in a way that is rigorous, quick, clear, consumable, and value-focused. 

    We are uncovering better ways of developing business insight by doing it and helping others do it.  Through this work, we have come to value:

    Consistently reusable methods over Piecemeal assortment of best practices

    Rapid insight over Deeply accurate models

    Clear choices over Nuanced decision trees

    Consumable deliverables over Consistency with external frameworks

    Value-driven prioritization over Justification of the status quo


    That is, while there is value in the items on the right, we value the items on the left more.


    To break that down:

    • Repeatability, Reuse, and Rigor.  There are many ways to understand a business.  Business architects will expect you to pick one of those ways (one conceptual model) and then stick to it.  The rigor comes from sticking to the model.  If your enterprise is focused on creating a smooth customer experience, then the business architect will leverage the customer experience work done elsewhere, and will drive a business stakeholder to follow along rather than make something up.  While products must be creatively and freely developed, the organization itself must be architected and engineered.  Rigor matters.
    • Rapid Insight. There are many ways to analyze a business.  Business architects will work to reduce the overhead of their analysis methods so that they can produce valuable answers in a very timely manner.  Business people are not rewarded for taking a long time to do an excellent job.  Most will be better rewarded if they do a reasonably good job in a shorter timeframe.  While accuracy is great, the value of information is inversely proportional to the time needed to produce it.  Speed matters.
    • Clear Choices. If a business person cannot tell what the recommendation is, they won’t follow it.  If the business architect cannot produce insight that is clear for the business stakeholder, the architect will not effect change.  It is not good enough for a business architect to be quick and correct… they must also be clear. 
      The amount of information, and the coarseness of the decisions, depends on the level of the stakeholder.  At any level, a decision maker should be provided a short list of options (often 2 or 3) where the distinctions between them are clear.  This rule applies at all levels of the organization.  One strategy from a senior manager may require a choice among three different tactics for a department head to choose from.  No one person needs to be concerned with the entire decision tree, except perhaps the business architect himself.   The ability to make decisions is proportional to the clarity of the choices.  Business architecture favors clarity over nuance.
    • Consumable Deliverables.  In order for business architects to be successful, they must deliver a plan for the execution of business strategy.  That plan has to be something that the impacted stakeholders can understand and use.  In other words, the output of business architecture must be consumable.  Reams of technical detail are rarely useful.  At the other end of the spectrum, vague goals and promises of value may be just as inappropriate.  Recommendations must be provided using words and metaphors that the actual impacted business stakeholders understand.  They must be provided using forms and templates that the existing organization will recognize and can quickly use.  While consistency with frameworks and practices are important, business architects value consumability more.
    • Priority based on Business Value.  Business architects can spend their time on many tasks.  In addition, they can recommend that the organization spend time on many tasks.  Sometimes, even an efficient use of business architecture would be a waste of time if the resulting advice is unlikely to deliver strategic insight.  The selection of tasks, which to do now and which to do later, is of critical importance to a business architect.  While all supporting tasks can be justified, business architects will give priority to tasks that directly lead to actionable, consumable, value-driven business advice.


    I’m always looking for insight and feedback from the community, so please feel free to add your comments. 

    Please note: if your comment is long, the software will sometimes have trouble.  Write it in notepad or Word first, and then cut and paste into the comment edit window.  Don’t be afraid to send it more than once.  I will delete duplicates.  If all else fails, e-mail your comment to me and I’ll put it in.

Page 1 of 1 (4 items)