Inside Architecture

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

August, 2010

Posts
  • Inside Architecture

    Introducing: Ecosystem Quality Attributes

    • 3 Comments

    There are benefits to taking an idea from one domain and applying it to another.  We all know of the famous case of “software patterns” that emerged from the concept of architectural patterns developed by Christopher Alexander for the world of building design.  Similarly, we have recently seen the emergence of checklists in medicine which is an idea borrowed from other complex domains (like airplane piloting).

    I’m going to follow in that long path of “cross-domain pollination” to take an idea from software architecture and apply it to business architecture.  Not a big stretch for an Enterprise Architect, I know, but I’ve not seen this idea discussed elsewhere.  (Just because an idea is obvious, that doesn’t mean people will think of it: witness the length of time it took to add wheels to luggage!)  That said, I leave open the possibility that prior art exists, and that I’m simply not aware of it.  If that is the case, please don’t hesitate to point it out.

    The concept I’m going to borrow from software architecture is that of System Quality Attributes.  They are the various “-ities” that a software system exhibits. These include Scalability, Reliability, Maintainability, and many others.  System Quality Attributes can be used to measure the ability of the system to meet business needs.  There are lots of ways to use SQAs but I am going to focus on one specifically valuable practice.  In my opinion, the best thing you can do with software quality attributes, during system planning, is to prioritize them.

    Prioritizing the relative importance of a system’s quality attributes, early in system planning, can have a dramatic impact on the design of the system.  The design is simpler, and more intentional, because the goals of the system are more clear.  A prioritized list of System Quality Attributes provides “guard rails” for the design of a system.  Creating this priority, and then driving a design to meet it, is the domain of the solution architect.

    Now for the new concept: Ecosystem quality attributes

    Ecosystem quality attributes are the specific measurable attributes of a coherent ecosystem of business processes, information systems, and human actors constructed to deliver the required capabilities demanded by an organization’s business model.

    At the highest level, an Ecosystem quality attributes may be applied across an entire operating model.  (For the sake of this approach, an operating model is the widest example of a business ecosystem).  EQAs may also be applied at the level of end-to-end business processes within an operating model. 

    Hypothesis: The relative priority of Ecosystem Quality Attributes can have the same dramatic effect on ecosystem design as we’ve observed at the system level through the prioritization of System Quality Attributes.

    Managing that relative priority of these attributes for each business model, and influencing the emergence of the operating model to deliver it, and then governing the systems within that ecosystem to insure that it comes into being, is the domain of the Enterprise Architect.

    Attribute Definitions

    In this section, I will outline a relatively useful set of Ecosystem Quality Attributes (EQAs) that an Enterprise Architect can use to measure their business ecosystem.

    Note that Ecosystem Quality Attributes measure a business ecosystem, and therefore must include information that is not available unless you work outside the “boundaries” of IT.  In other words, using a system of EQAs to measure a business ecosystem is a business method, not an IT method.

    Ecosystem Quality Attribute Description
    Operating Model Alignment A measure of how well the ecosystem of processes, information, systems, and roles align to meet the business model and operating model requirements of the enterprise.  The business model places specific requirements on the ecosystem, requirements which may change as external influences, opportunities, customers, and markets change.  Systems that do a poor job of keeping up the the changing requirements of the market incur a “tax” on customer loyalty, top line revenue, customer service costs, and operational efficiency that is difficult to address without systemic change.
    Federation Consistency A measure of how well the ecosystem supports, defends, and enforces the vertical division of duties, responsibilities, and accountabilities demanded by a federated decision structure.  Federated decision structures are very important in each of the four CISR operating models, but they apply in different ways with different amounts of federated control.  The ability of the system to keep “true” to the principles of federation intended for the ecosystem, with a minimum of unnecessary stress, is reflected by this measure. 
    Collaborative Maturity A measure of how well the people and processes within an ecosystem support collaboration, ranging from information sharing at the low end, continuous measurement as a normal practice, and continuous improvement at the high end.  Core contributors to collaboration effectiveness, like shared commitment, consistency, culture, and expected level of rigor, all play into the level of collaborative maturity of a business ecosystem.
    Dependency Risk A measure of the relative strength of the ecosystem as indicated by the number of dependencies taken on immature capabilities, information sources, systems, and shared processes.  A business process that takes a dependency on a weak supporting system accepts an increased level of risk as a result of that dependency.  Business leaders may decide to reduce the number of dependencies or increase the maturity of the supporting systems, based on their preferences for business efficiency and effectiveness.
    Information Consistency A measure of the consistency of the core information elements across the breadth of an operating model.  A low level of consistency drives a “hidden tax” on efficient operations and business intelligence that is difficult to quantify.  Higher consistency reduces this tax, improves information velocity, and can have dramatic impacts on the ongoing costs of maintaining a business intelligence infrastructure.
    Interaction Complexity A weighted measure of the number of interaction points between independently managed business elements (business units, information systems, master information stores) needed to perform core business processes within the ecosystem.  Weight is applied to interaction points indicating the level of standardization and isolation in the interactions themselves, so that factors that lead to increased cost of ownership drive up the measure.
    Readiness Complexity A measure of how difficult it is for stakeholders to the ecosystem to learn to behave within the expectations of the business processes and culture of the ecosystem. 

    This includes readiness with respect to key scenarios, customer requirements, conceptual ontologies, key decisions, governance mechanisms, implementation details, systemic problems, planned roadmaps, change project status, and outstanding list of incidents.

     

    Open question: is this the “right” list?  Am I missing elements?  Are there attributes that are not important from an ecosystem standpoint, and if so, why?  Answering these questions will require research, and is beyond the scope of this article.  I am more than willing to consider this list to be an “initial draft” for the use and refinement of the EA community. 

    Prioritization and Tradeoff Method

    It is a well-accepted premise, in software architecture, that there is no such thing as a perfect system.  A system has to be optimized for its use, and in doing so, the designer of the system has to apply tradeoffs.  We accept this idea without thinking in our daily lives: that a car can be designed for speed, or towing capacity, or gas mileage, but you cannot optimize for all three.  You have to set up your priorities, and optimize the system on the basis of those priorities.  A Sport-Utility Vehicle may put a priority on towing capacity first, acceleration second, and gas mileage last.  A small commuter’s car may reverse those priorities.  Both are acceptable.

    I posit that the same is true for business ecosystems.  There is no perfect operating model or end-to-end business process.  Each is designed to suit the specifics of the business that demands it, and the business culture that drives it.  Each business ecosystem has to be optimized for specific quality attributes, and priorities must be taken.

    So the challenge of this level of business architecture is to illustrate the importance of these attributes and host a discussion, among your business stakeholders, about the relative priority of each.  The deliverable is a simple document illustrating that priority and commenting on the intentional tradeoffs that result. 

    What are some of the questions that your business leaders will consider:

    • How important is it that your business be constantly improving?  Is it more or less important than the need for information consistency? 
    • Does your business culture foster interdependency or would you prefer federation? 
    • Do you need to be able create a copy of yourself, where readiness matters, or can the business take on large scale interaction complexity in order to create market differentiation for the products and services?

     

    The process works like this:

    1. Present the ecosystem quality attributes (in concrete terms, with example tradeoffs) to a set of senior execs and host a discussion.
    2. Create a simple document resulting from the discussion that outlines the “decision criteria” that managers should use when improving their processes and systems.
    3. Run that document past the execs to make sure that they agree with your distillation of their ramblings, and with your plan to communicate the results.
    4. Communicate the resulting priorities to mid-level managers, key subject matter experts, and the folks involved in making changes to the business (especially Quality, BPM, and IT professionals who are frequently involved in tradeoff decisions).

     

    Value proposition

    So why should we host this discussion?  What is the value of taking the time of senior business leaders to make them consider the relative importance of complexity, consistency, readiness, (etc) in their business? 

    The value is in building a company that knows what it wants, knows how it will go get what it wants, and wastes as little time, as possible, debating the relative merits of obscure decision points, or fighting political battles based on competing business goals.  The value is in clarity.  If you WANT a company that is able to replicate itself at the drop of a hat, say so.  If, on the other hand, you want a company that uses a complex set of interactions in order to create a wide array of different services in the marketplace, saying so will reduce internal “churn” that occurs when smart people are left to their own guidance about what is the “right thing to do.”

    Example (Help Wanted… Looking for victims volunteers)

    When I outlined this blog post, I thought “I will describe this concept with an example, here.”  However, as I got to this section, I decided that it would be more effective to ASK for your input than to tell you what an example should look like.  So… I’m looking for volunteers.  If you are an EA or a Business Architect, and you’d like to submit yourself to a two-hour telephone call where I ask you probing questions about your business model, business culture, and business behavior, then I’d like to hear from you.  Taking your input, I’d like to produce a couple of sample “ecosystem quality attribute prioritization documents,” and using that experience, refine the method. 

    So if you are game for a phone call, drop me a line.  I will be in the New York/New Jersey area in about two weeks, and in the Chicago area for a few more days, in mid September.  If you’d prefer to meet in person and it works out to be convenient, perhaps we can do this face to face.  Respond by clicking the link labeled Email Blog Author in the upper right hand corner of the page.

    Conclusion

    I don’t find it “startling" or “novel” to say that Enterprise Architecture should directly impact the structure, function, or responsibilities of various business units.  My readers know that this is not a new proposition for me.  To the contrary: I believe that an EA that does NOT have the intent of impacting the business itself (in terms of business unit alignment, processes, roles, scope, funding, or vision) is not performing the role of an Enterprise Architect. 

    The EQA concept and method is very much in the domain of Enterprise Architecture, not IT.  This method is concerned with the measurement of the structure and function of the business itself.  Where that structure and function is influenced by software systems, then IT folks would provide input.  Information Technology is not, however, a predominant concern. 

    That said, the business method I described borrows shamelessly from the concept of System Quality Attributes and the ATAM architectural method.  I believe that the concept is sound and that a rigorous approach to business architecture, along the lines outlined here, has the potential for providing clear, simple, and elegant guidance to the army of business people (including IT folks) that are charged with taking the often-nebulous intent of business leaders and translating it into an effective, intentional, enterprise.

    As always, dear reader, I’d love to hear your feedback.

  • Inside Architecture

    On vacation

    • 1 Comments

    ...at a really great place.  I'm at Rancho La Puerta, a "destination spa" in Tecate Mexico (just south of the US border in the Baja California). 

    Now that my wife and I have been here a couple of days, I can heartily recommend the experience.  I am eating healthy, delicious food, prepared by excellent chefs, grown organically on site.  I am enjoying activities like Tennis, Sand Volleyball, Latin Dancing, Yoga, and Ballet, in addition to "normal" fitness activities like Fit-ball, Circuit training, and water aerobics... and that is just in the first two days.  Climbed a mountain this morning.  I'll post photos on Facebook. 

    Big rounds of appreciation to my dear Mother-in-Law for agreeing to spend time with my kids while we are here... and big hugs to my three angels for behaving for their grandmother (hopefully ;-).  But most of all, a long, warm, slow hug for my darling wife Marina, for putting up with me for twenty years (as of September 1).  No one is luckier, more blessed, and more grateful than I am.

  • Inside Architecture

    When demand management is confused with alignment…

    • 7 Comments

    One of the most common, and reasonable, mechanisms for achieving clarity on the roadmap for a single platform is “demand management.”  It is also one of the areas of IT that is both rapidly evolving and poorly defined.  I’d like to offer an opinion about what demand management is, and is not, and how it meets some, but not all, of the planning and governance needs of IT.

    Caveat Emptor: In the post below, I’m sharing my opinion, which will probably differ from yours.  I ask that you follow along with an open mind, and consider the possibility that we may be using the same words in different ways, before pointing out how “wrong” my thinking is.  That said, I would love to hear feedback from others, and to improve my own thinking in this space.  Please share your thoughts.

    Assertion 1: IT Demand Management is poorly defined.

    In the book “IT Success: Towards a New Model for Information Technology” author Michael Gentile provides a reasonable description of demand management… or at least he starts to.

    Using the fundamental premise that not all demand from the business will be approved—because of business priorities on the one hand, and IT resource and scheduling constraints on the other—the best way of representing demand would be via a funnel. Demand from the business enters at the top, follows one or more decision-making processes, and then either exits at the bottom as approved work to be executed, or remains in the pipeline pending further evaluation. – Michael Gentile, “IT Success: Towards a New Model for Information Technology” as excerpted in CIO magazine (link)

    This is a reasonable explanation of what demand management is.  As a more formal definition, IT Demand Management is the practice of collecting together all of the demands that will be fulfilled by a particular IT group, team, or organization, and balancing all of those demands with the limited supply of resources in order to produce an ordered list of activities, on a specific timeline, for that group, team, or organization to fulfill. 

    Assertion 2: Demand management does not deliver alignment

    Unfortunately, if the article in CIO that I cite above is any reflection on Mr. Gentile’s book, he goes wildly off the rails, describing demand management as the process by which IT achieves alignment and delivers value.  That is an interesting notion but it is fairly easy to disprove. 

    What proof do I offer?  A counter-example.  Microsoft IT has been performing the kind of demand management that Mr. Gentile describes for well over a decade.  At no time did demand management deliver alignment.  When alignment was achieved, it was achieved in spite of, or regardless of, the maturity of the demand management process, and not because of it.

    Alignment happens when a team or group of people decides to build the right solution, instead of building the solution right.  But more importantly, alignment occurs when a team decides NOT to build something, or to build something less than was requested, or in a different order than requested, because it meant that the business was more able to deliver on strategic goals. 

    Mr. Gentile and I agree on this understanding of alignment.  We disagree that demand management gets you there.

    Assertion 3: Alignment processes occur BEFORE demand management processes

    Starting with demand is important and useful… if you already have a solution, and that solution has demand.  Once you have a solution, you have to manage the demand against that solution.  You don’t have infinite resources.  So if there are four teams within your company that want to use your public website to meet their goals (let’s say lead generation, ecommerce, customer support, and investor relations) but only one team that can manage the public website, then you will need to use demand management.  You need to collect the requirements from different teams, go through a rational and mature process for prioritizing those requirements, create a roadmap showing which requirements to meet in which order, communicate that roadmap, and track to it.  That is demand management.

    However, if you THINK you need a solution to a problem, and you are a business leader, your request could go into a demand management “funnel” and come out the other end producing a solution to a problem that you did not have.  That is misalignment, and demand management will do little or nothing to prevent it.

    Alignment requires a different process, one that examines the goals of the business, rationalizes them, finds common impact areas, and FRAMES THE DEMAND.  Alignment decides what demand is rational.  Alignment occurs BEFORE the demand management process does.  To accept all demand against IT without performing alignment activities first is an anti-pattern.  Demand management practices lend an air of “officialness” to the resulting roadmap, and once that roadmap is produced, it is very difficult to come back to the project teams and point out that the hard-won priorities don’t align to business strategy!

    Discussion and Conclusion

    These are tough assertions for many IT folks.  This is one of the major reasons, in my opinion, that Enterprise Architecture is often unwelcome within IT, but well received outside of IT… because Enterprise Architecture attempts to achieve alignment in spite of the often well established practices of IT demand management.  Without clear understanding of the dependency that demand management SHOULD take on alignment, the processes will conflict.  Demand management will produce a list of things to do, and alignment will produce a different list.  The only way to reconcile this is to perform alignment activities first, and then demand management activities, to produce the ultimate roadmaps.

    That is my perception, anyway.  I know that some folks will assert that demand management is a larger process, and it includes the “alignment” activities that I speak of.  That may be an interesting matter of semantics.  However, if this were true, then the “funnel” metaphor breaks down, because any demand management process that includes alignment activities would not resemble a funnel.  In a funnel, all of the stuff goes in the top and the stuff coming out of the bottom is a direct reflection of what went in the top.  Alignment assumes that most of the stuff going in the top is wrong, and that a lot of stuff is missing. 

    The “funnel” metaphor for demand management is accurate, as long as demand management doesn’t deliver alignment… and it doesn’t.

    Your thoughts?

  • Inside Architecture

    The Mission, Capabilities, and Business Output of Enterprise Architecture

    • 8 Comments

    In the response to my most recent post on Enterprise Architecture, Brenda Michelson posted a very interesting question:

    I think the number one question Enterprise Architects and Enterprise Architecture Practices need to answer is “What do we contribute to the business”.  What is the ultimate outcome of Enterprise Architecture?  And therefore, what would be missing (or more difficult) without Enterprise Architecture – Brenda Michelson

    Nothing will focus your mind on a process better than considering the output.  I’ve been focused on that notion quite a bit lately.  In meeting after meeting, in discussion after discussion, I’ve been thinking about the output of EA.  I am in “violent agreement” with Brenda on this point: we must focus on the results, and more importantly, we must focus on what would be different in the absence of Enterprise Architecture.

    • If we provide alignment, does that mean that without EA, there is no alignment?  Or is there bad alignment?  Or is there random alignment?
    • If we provide information for good decision making, does that mean that without EA, there is no information for good decision making?  Bad information?  Incomplete information? 

    Business people care about the health of their business.  Answering the questions above in the wrong way will produce a declaration about the value of EA that is condescending at best, and downright insulting at worst.  “What do you mean, our information is not good enough!  Who the heck are you, anyway!”  Not a fun conversation. 

    The Mission of Enterprise Architecture


    In order to understand the difference we make, let’s create a mission for Enterprise Architecture.  Let’s answer the question: “why are we here?”

    In my experience, EA exists to do two things:

    1. to Envision an organization that includes the strategic and operational changes that leaders require and demand, and
    2. to Guide changes to the structure of the organization, and the actions of the business units themselves, so that the vision becomes reality. 

     

    To Envision and to Guide.  Sounds easier than it is.

    1. First, the business leaders have to be clear about the changes that they are demanding.  EA has an effect in this space by helping business leaders to describe their business goals in an accurate and actionable manner.  Without EA, business leaders may not have an internal team with the charter of insuring actionable strategy. 
       
    2. Second, you have to have a good understanding of the organization, so you can focus resources on the changes that are actually needed.  We have an effect by helping to identify the areas of the business that need change in order to fulfill strategic desires.  There may be a long list of “problems” in a business.  EA is there to assist in selecting the right ones to go after.  Without EA, business leaders may not have an internal team with the charter of finding the specific areas for change that are needed to meet the needs of a strategy.  The result would be the frequent loss of energy, time, and money as key dependencies go unaddressed. 
       
    3. Third, you have to have a good system of governance to insure that approved business plans are not thwarted by the currents of time, conflicting initiatives, and poor communication.  Without EA, business leaders may not have a consistent and clear mechanism for reporting progress in changing the organization to meet the needs of business strategy. 
       
    4. Fourth, you have to have a grasp on the potential for innovative application of processes, enterprise relationships, new business models, and new technology trends.  This is a serious source of insight for the formation of new business strategies, both at the high level (new business models) and at the detailed level (new efficiencies through the application of technology).  Without EA, business leaders may not have an internal team with the charter of evaluating new ideas and business models with the goal of bringing new approaches to the table. 
       
    5. Fifth, you have to have the ability to provide repeatable process guidance and standard methods designed to insure that specific actions by individual contributors are likely to produce the intended outcomes.   (Keeping the devil out of the details).  Without EA, business leaders may not have a dedicated internal team focused on providing “instructions for change” to the individual contributors in the organization where their lives are most impacted. 
       

    Now comes the fun part… you will notice that I underlined the word “may” in each of the statements above.  Each of these needs may already exist, in some form or another, in your organization.  Those needs could be distributed in different places, and can be inconsistently performed.  Consulting agencies make a great deal of money filling in these roles on an occasional basis for large companies.  Business leaders may have a single person or a small team whose job is to solve for a specific set of problems that looks an awful lot like a collection of these needs. 

    So when EA comes on the scene, there is a great deal of gentle negotiation.  EA team members cannot simply “jump in” and take on strategic roles that are being filled by another trusted advisor.  They have to provide value, often to the effect of strengthening those other advisors. We can often be most effective by making other people more effective.  We can be more valuable by making other people more valuable.  Over time, if we have earned the right to be direct players, instead of indirect players, we will be trusted to do the work that so many folks describe as Enterprise Architecture. 

    That takes time, patience, and careful awareness of how the “lines of influence” work.  It is not a job for the novice. 

    Brenda’s Proposal


    Brenda made a specific proposal in her response that I’d like to address in context of this blog post:

    I propose we think of EA as a business and work backwards from the desired outcomes -- ease of change, reduction of complexity, and better technology investment return.  To achieve those outcomes, what capabilities, policies, people and tools are required.  And then, how would we describe (classify) that?  -- Brenda Michelson

    With as much respect as I can muster, I find that I must disagree with Brenda here.  I would not frame the value of EA as “ease of change, reduction of complexity, and better technology investment return.”  Those are each “operational strategies.”  They are NOT universally applicable to all companies.  Some companies will not be focused on reduction of complexity.  I agree that there are persistent underlying problems that need to be addressed, and that EA impacts them, but I would not use that impact to justify EA.

    Even within a company, many business leaders would not find these underlying problems compelling.  If I was to ask a business leader (outside the COO) about the relative importance of an operational strategy like “reduction in complexity” compared to “increase our market share in Asia", I can easily predict their response.  If I was to ask the COO about these strategies, he or she would probably LOVE them, but would put them below “increasing market share in Asia” in priority.  It is not enough to be a supporting function for a supporting function. 

    On the other hand, I could say “to increase market share in Asia, we must provide a mechanism that encourages our partners to move more of our products, and the root cause of partner resistance is the price and difficulty of using our sales model.  W can address these concerns by leveraging consistent information across channels and, through process simplification, reducing the cost of our products to suppliers.  The resulting efficiencies, passed on to the partners, would reduce costs and improve partner experience, thereby producing a greater market share.” 

    What I did was use the business strategy (market share) as a “compelling event” for addressing the persistent underlying problems of ineffectiveness, inefficiency, complexity, and resistance to change.

    Talking about the persistent underlying problems is useful when we speak to our peers.  It is simply not compelling when justifying the existence of EA to the people who decide our fate: executives.

    The Key Capabilities of Enterprise Architecture


    Back to the list above, let’s pull aside those effects that I outlined, and as Brenda asked, let’s look at the capabilities demanded by them.

    1. Capability: Strategy Formation – EA will perform a key role in advising business leaders on the formation of actionable strategy.  That requires EA to

    • (a) be able to define what an actionable strategy looks like,
    • (b) have trained resources able to assist with reviewing business goals and offering insight and guidance on making them more actionable, and
    • (c) have the positioning within the organization to play a role in strategy development.

    2. Capability: Comprehensive knowledge of the opportunity areas of the business – EA will leverage a rich base of understanding of the functions and structures of the business in order to focus business strategies on the key problem areas that need to be improved.  That requires EA to

    • (a) maintain a rich base of business knowledge including information about business units, processes, technologies, locations, business products, partnerships, etc,
    • (b) have a process for quickly connecting business strategies and goals to the areas of the business needing improvement,
    • (c) have people trained to collect the needed information for the production of strategic roadmaps indicating the order, timing, and scope of specific initiatives, and
    • (d) have the positioning within the organization to insure that the resulting roadmaps can influence the process of approving and funding those roadmaps.
       

    3. Capability:  Governance processes – EA will influence the performance of business governance to insure that the projects that are performed reflect the strategic roadmaps identified in earlier stages.  That requires EA to

    • (a) have direct contribution to, and accountability for, the development of a corporate governance process,
    • (b) the resources able to evaluate progress by various teams and to determine if their progress meets the requirements of the roadmaps, and
    • (c) the positioning within the company to point out the flaws and impacts that may result when a team misses its goals.  

    4. Capability: Innovation generation – EA will be part of the system of thought leaders that assist with the generation of new business strategies, especially as it applies to the application of technology-focused innovations in the marketplace.  That requires EA to

    • (a) have a regular process for collecting and examining ideas from both external and internal sources with the ability to produce an estimate of the impact to the business if that idea is adopted,
    • (b) a mechanism for funding the deeper examination of promising ideas through proof-of-concept development and business projections to validate the feasibility of new ideas, and
    • (c) the positioning needed to expose new ideas to strategic leaders on a regular basis. 
       

    5. Capability: Standard and Policy Governance – EA will be part of the system of change agents that develop specific instructions for changing the behavior of individual contributors and reviewing their behaviors over time to insure that changes have taken hold.  EA will be accountable for guiding changes needed for strategic projects, a subset of all change projects and will likely represent only one source of policy and standard changes.  This requires EA to

    • (a) have reasonable and comprehensive knowledge base of company standards and policies that they can work with,
    • (b) have a process for examining strategic needs and developing standards necessary to ensure that strategic decisions produce long-term desired outcomes across a wide array of roles, behaviors, and systematic activities.
    • (c) have the necessary position to provide feedback to teams and business groups on their performance of business policies and standards in a manner that produces better compliance in the long run.

     

    How to use this post


    In this post, I describe the capabilities needed by an EA team in order to fulfill the mission that I outlined above.  Clearly, if you disagree with the mission statement, you will expect to see different capabilities highlighted.  I would be surprised if any EA team adopts the mission statement above without tailoring it to your own organization.  I want to be clear: our own internal Microsoft EA mission statement is different from the generic statement above. 

    However, this can be useful analysis in producing your own mission statement and statement of capabilities.  Your list of capabilities will be different than mine!  That’s OK.  Once you have produced that statement of capabilities, you can set out to measure yourself.  You can look at each capability and determine if that capability is mature in your organization. 

    By determining the capabilities you need, and evaluating the capabilities you have, you can produce your own roadmap to a more mature EA organization.  In doing so, you will develop your own business model illustrating the situations where you can (or must) be indirect, supporting other business units or business functions, in order to have the desired impact.  That is your business model. 

    Your value proposition, for your EA team, will be unique, especially at first.  Until your organization takes a dependency on Enterprise Architecture, and begins to establish trust, and your team develops the position needed to have the influence you should have, your value proposition will not be “ideal.”  Your value proposition will evolve, probably on a frequent basis, until you hit the “sweet spot” that is specific to your organization, business culture, and leadership climate. 

    If you do decide to use this kind of analysis for developing the value proposition of your EA team, I’d love to hear about it!  Please share. 

  • Inside Architecture

    A reasonable canonical definition of Enterprise Architecture

    • 17 Comments

    Clearly we want one.  A thread on LinkedIn a couple of months ago attempted to define the value of EA, and produced a tirade of over 1,300 entries!  But while individuals were busy chatting, the Enterprise Architecture Research Forum took a different approach.  This body is a collaborative including the Open Group South Africa, the Meraka Institute, Real IRM, Telkom, Unisa and the University of Pretoria (link). 

    This group started with a “definition of definitions.”  In other words, they thought about the requirements of a definition before producing the solution.  (What a novel idea :-). The requirements that they used come from a paper by Dr. Sam Vaknin.  Dr. Vaknin’s definition of definitions indicates that a definition should explain the meaning, use and function, essential characteristics, and the differentia of the concept. (link)

    Using this model, the EARF created the following definition:

    Enterprise Architecture is the continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change.


    Let’s compare that definition to the “compromise” definition that emerged out of the “160 character challenge” on LinkedIn.  The LinkedIn thread that I’m referring to started as a post, by Kevin Smith (author of the Pragmatic EA Framework, or PEAF).  Kevin asked participants to define the “value” of Enterprise Architecture in a message short enough to send in an SMS text message.  While the length constraint was arbitrary, it was useful for insuring short responses.  Kevin then collected the data and, in a fairly rigorous process, analyzed it to produce a more succinct definition (link). 

    Using the responses as a guide, Kevin found that three different aspects of Enterprise Architecture were appearing over and over in the various definitions so his construct includes all three.  He refers to these aspects as the “why, how, and what” perspectives.   Kevin’s combined definition follows:

    The purpose of Enterprise Architecture is to enable an enterprise to realise its Vision through the execution of it’s Mission, whilst enabling it to respond to change and increasing its effectiveness, profitability, customer satisfaction, competitive edge, growth, stability, value, durability, efficiency and quality while reducing costs and risks by Strategic Planning, Architecture and Governance supported by a Decision Support framework in the context of aligning all parts of the enterprise using Models, Guidance, Processes and Tools.

    Now, to be completely fair, I participated in Kevin’s “160 character challenge” on LinkedIn.  I do not have a single definition of Enterprise Architecture… I have three.  Just as a dictionary may show you many definitions for a word, I have found that the term Enterprise Architecture is used in three different ways: As the name of a business function, a reference to a team of people, and as a reference to a model that describes an enterprise. 

    When creating my submission, I was not being particularly rigorous, so I see flaws in my definition as I type this blog entry. (to whit: EA is not limited to businesses).  That said, I will cite my original words rather than revise history.  Note: In order to fit into Kevin’s challenge, I submitted each of my definitions independently.  Recombined as a single definition, my contribution was as follows:

    Enterprise Architecture -

    -- Noun


    1. A business function that collects and manages business information for the purpose of improving the way that a business responds to current or future challenges and opportunities.


    2. A rigorous model of the motivations, structures, information, processes, and systems of an enterprise created for the purpose of decision support.


    -- Adjective (used with object)


    3. A team of influencers and thought leaders within an enterprise chartered with understanding, optimizing, and improving the way the business operates.


    Is there a right answer?  Which of these is a better definition?  Which misses the point?  Could we improve one of these entries and recognize it as canonical?  Is there a better definition of Enterprise Architecture, and if there is, what would it be? 

    What is your opinion?

  • Inside Architecture

    Tangled

    • 0 Comments

    Barry Briggs put together a tag cloud for the Technology Office a few days ago… that inspired me to put together the cloud below.  I guess the thing that strikes me the most is that I’ve been an Enterprise Architect for five years now… and five years ago, when I was a solution architect, I didn’t really use these terms very much.  This is where I live now.  Who knows what the next five years will hold?

    image

Page 1 of 1 (6 items)