Inside Architecture

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

Posts
  • Inside Architecture

    Business Models in Business Architecture

    • 4 Comments

    It still surprises me to see various discussions of business architecture where there is a poor understanding of the relationship between business models and business capabilities.  The vast majority of discussions of business architecture, including books, articles, and blogs, make very little mention of business models, and nearly never discuss their relationship with business capabilities, organizations, stakeholders or resources. 

    To me, the concept of a business model is fundamental to using business capabilities.  I cannot imagine attempting to understand a commercial organization without understanding the business models of that organization as a first step. 

    In this post, I will discuss the reasons why business architects must consider business models.  I’ll start with some definitions to minimize confusion, given the fact that everyone has different definitions of these concepts.  I’ll then discuss the concerns that I have about the lack of integration of core concepts.  In a future post, I will discuss the various information models for including business models into business architecture as well as needed changes to business architecture methods (including capability analysis) in order to correctly place this role.

    Caveat Emptor: The following discussion of business models will focus on commercial systems.  If you are examining this space from the standpoint of a non-profit organization or government agency, your needs may not be well represented.  My apologies.  The reason for this will be immediately apparent when you read the definition of “business model” below.

    Definitions

    The Business Architecture Society and the Business Architecture Guild have joined forces and created a common definition of a “business capability.”  From the Business Architecture Body of Knowledge Handbook: “A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.”  Note that the BIZBOK cites Ulrich Homann as the originator of the definition.  For the sake of this discussion, let’s take this definition as a given.

    There are many definitions of a business model.  Perhaps the most popular definition today comes from Alexander Osterwalder, author of the popular business book “Business Model Generation.”  However, his book doesn’t have the same level of discussion of a definition as the Ph.D. thesis that he wrote in which he defines a business model as follows.  “A business model is a conceptual tool that contains a set of elements and their relationships and allows expressing a company’s logic of earning money.  It is a description of the value a company offers to one or several segments of customers and the architecture of the firm and its network of partners for creating, marketing and delivering this value and relationship capital, in order to generate profitable and sustainable revenue streams.” [Osterwalder, 2004]

    Osterwalder carefully notes that a business model is not a representation of the business organization itself.  He states, and I concur, that the business organization is the “material form that the conceptual business model takes in the real world”. [Osterwalder, 2004]

    I will also take a moment to define business strategy.  This time, from Kaplan and Norton: Business strategy is a description of how an organization intends to create value for its shareholders, customers and citizens.  Note that this is not the same as a business model. Osterwalder addresses this distinction by illustrating that one can view strategy, business model, and process model as a three-tier hierarchy.  The top level, business strategy, describes the conceptual approach to business change.  The business model goes into more detail, describing the relationships between various components.  The third level, process, illustrates the association of activities to the people and business functions that will perform them.  All three are necessary, but all three are different in level of detail and analysis.  The following picture is directly from his Ph.D. thesis (click to enlarge for readability).

    Osterwalder

     

    Concerns

    One of the challenges in bringing together these concepts is the fact that most business architecture references make no mention of business models or describe business models as a “side concern”, and most of the business model literature makes no reference to business capabilities.  I attempted to address this gap in the paper where I introduced the Enterprise Business Motivation Model, back in 2008.  While the model has dramatically improved since then, the core motivation remains the same: to integrate these two concepts into a single coherent approach to understanding and modeling a business.

    Business architecture cares about the organization of a company.  It also cares about the resources or tools in a company.  Business architecture cares about the processes, and the information.  These elements are all brought together in the understanding of a business capability.  Business architecture also cares about strategy.  However, as Osterwalder notes, connecting strategy to organization or processes without an understanding of the business models is a partial understanding at best.

    Let’s be clear about one thing.  Business strategy is related to business models.  In fact I will go further to say that all effective business strategy applies to one model at a time.  Business strategy that applies to more than one model is not strategy.  It is either a goal, a principle, or a vision of some kind.  A strategy, by definition, has to express “how” the goal will be achieved, and that requires the context of a business in which to achieve it.  I know that this may be controversial, but it is CORE to my understanding and the experience I want to share.

    So let’s look at the viewpoints of business model proponents and business architects.

    So what if these two viewpoints differ?  What’s the downside?

    There are a number of problems within large organizations that cannot be solved by business architects without a consistent and careful understanding of business models.  These problems are tenacious and challenging.

    1. Conflicting strategies: Most large organizations have many business models.  Frequently, there are senior leaders who are focused on making one business model successful without any concern for other business models.  Those leaders will create strategies for improving their model, sometimes to the detriment of other leaders and their models.  This leads to political infighting and friction as teams reporting to different leaders are left to “fight it out” when one strategy directly conflicts with another.
    2. Inconsistent understanding among Leaders: It is common for business leaders to be only vaguely aware of the potential for interaction between their model and the models of other leaders.  Therefore, their words and actions will not reflect a consistent and mature understanding of those other models.  This drives serious inconsistencies into their organizations.  This lack of consistent understanding turns into poor assumptions, simplistic rationalizations, and invalid arguments. 
    3. No prioritization produces confusion among shared services: Without understanding what the models are, it is impossible to rationally prioritize the relative importance of those models to the success of the enterprise.  However, it is quite common that multiple leaders leverage shared services within an enterprise (like human resources, legal and IT).  Without the ability to prioritize and create constructive conversations, these “shared functions” are driven to create complex and conflicting services that are expensive to maintain and resistant to change.


    I would like to suggest that three of the key value propositions for business and enterprise architecture lies in addressing these specific challenges.  In other words, Business architecture is only effective if it copes with conflicting strategies, inconsistent understanding, and indecisiveness caused by poor prioritization.

    Conclusion: Including business models directly into the business architecture practice is critical to quality.  Failure to include them is a recipe for disaster.

  • Inside Architecture

    We do what you say we will do – Integrity By Architecture

    • 4 Comments

    One of the chief complaints of senior executives in midsize and large companies is that their organizations don’t “execute” on the goals that they set.  This concern is so common, it’s the butt of jokes.  Entire systems of governance and measurement are created specifically to provide assurance to senior execs so that they can maintain some level of public integrity.  Yet, when Enterprise Architects describe their roles to their peers, it is surprisingly rare to hear them talk about this issue.  That is a mistake.  Let’s talk about how to tell the story of Enterprise Architecture as the maintainer of executive integrity.

    In 2003, when Motorola sent their CEO Chris Galvin packing, USA Today wrote about what a “good guy” he was:

    He turned out to be a lackluster CEO, which, sadly, often seems to be the case when good guys land in the corner office. Friday, Motorola said Galvin would resign. Motorola under Galvin had suffered through six years of disappointing results, laid off one-third of its workforce, failed hugely on new ventures like Iridium, and waited for turnarounds that never happened. The board apparently had had enough; Galvin thought he'd better leave.

    I have to say I feel bad for Galvin. Of course, I wasn't a Motorola shareholder who watched the stock go from $60 (split-adjusted) in 2000 to about $11 last week. Nor am I a laid-off Motorola employee. And yes, Galvin was paid handsomely: $2.8 million in salary and bonus last year.

    Did Galvin fail, or did Motorola fail to execute on Galvin’s strategy?  The board of Motorola, and the board of any company, won’t see a difference.  Note that this story has happened over and over in high-tech, from Steve Ballmer to Michael Dell, usually without the board firing their CEO.  Far from being limited to high-tech, stories abound of retailers (Best Buy), manufacturers (General Motors), and financial services companies (too many to name) that have suffered through strategies that failed to pay off.

    Here’s what stockholders see: you said “X” would happen and it didn’t.  You lied. 

    From their perspective, the CEO loses credibility for lack of integrity.

    Integrity is a personality trait and a virtue.  A person has integrity when they can be trusted to perform exactly as they said that they would perform.  In other words, they “do what they said they would do.”  This person makes a commitment and keeps it.  This means that they make commitments that they are fairly sure that they CAN keep, and they don’t forget the commitments that they made.  In every high-performing team that I’ve been a part of, each member had a high level of integrity.  Integrity is key to developing trust.  If you do what you say you will do, people will trust you.

    Executives need to develop trust just as much as individual contributors do.   For private for-profit organizations, those stakeholders own stock, and purchase the goods and services of the company.  For public organizations, those stakeholders are voters and legislators.  Where an individual contributor must earn the trust of his manager and his or her peers, an executive is in a very visible position.  They have to build trust daily. 

    Building that trust requires that they make bold pronouncements about the things that the organization will do under their leadership… and then their organization has to perform those activities.  And that’s a key difference.  When an individual contributor says “I will do this,” they are talking about their own performance.  Rarely are individual contributors held accountable for failures of the people that they cannot control.  Executives, on the other hand, are not talking about their personal performance.  They are talking about the performance of the many (often hundreds, sometimes thousands) of people under them. 

    An executive doesn’t actually “control” the people under him.  He or she must lead them.  Sure, there can be an occasional “public hanging” (as Jack Welsh used to encourage), but, for the most part, the executive’s ability to speak with integrity comes from the trust he has in his organization to perform.  In other words, how will with “they” correctly do what “I” said they would do?

    Enterprise Architecture is a keeper of executive integrity

    Enterprise Architecture is the only profession (that I know of) that is focused on making sure that the strategy announced by an executive actually comes to pass.  Enterprise Architects exist to make sure that the needed programs are created, and executed well, keeping in mind the end goals all along the way.  EA’s go where angels fear to tread: to execute strategies and produce the desired results if they can be produced. 

    If you value executive integrity, EA is an investment worth making.

  • Inside Architecture

    Placing Architecture Properly into Scrum Processes

    • 3 Comments

    As I’m about to complete my share of a longer engagement on using Lean principles to improve the processes at an online services firm, it occurred to me that the efforts we undertook to properly embed Architecture practices into their Scrum process were novel.  I haven’t seen much written about how to do this in practice, and I imagine others may benefit from understanding the key connection points as well.  Hence this post.

    First off, let me be clear: Agile software development practices are not at all averse to software architecture.  But let’s be clear about what I mean by software architecture.  In an agile team, most decisions are left to the team itself.  The team has a fairly short period of time to add a very narrow feature (described as a user story) to a working base of code and demonstrate that the story works.  The notion of taking a couple of months and detailing out a document full of diagrams that explains the architecture of the system: pretty silly. 

    The value of software architecture is that key decisions are made about the core infrastructure of the system itself: where will generalizations lie?  Will a layered paradigm be used, and if so, what are the responsibilities of each layer?  What modules will exist in each layer and why will they be created? How will the responsibilities of the system be divided up among the layers and components?  How will the modules be deployed at scale?  How will information flow among the modules and between the system and those around it?

    The way these questions are answered will indicate what the architecture of the system is.  There are many choices here, and the “correctness” of any choice is a balance between competing demands: simplicity, security, cost, flexibility, availability, reliability, usability, correctness, and many more.  (These are called “System Quality Attributes”).  Balancing between the system quality attributes takes thought and careful planning.

    So when does this happen in an agile process?

    Let’s consider the architect’s thinking process a little.  In fact, let’s break the software architecture process into layers, so that we can divide up the architectural responsibility a little.  You have three layers of software architectural accountabilities.  (Repeat: I’m talking about Software Architecture, not Enterprise Architecture.  Please don’t be confused.  Nothing in this post is specific to the practice of Enterprise Architecture).  All this is illustrated in the diagram below.  (Click on the diagram to get something a little more readable. 

    image

    At the top, you have the Aligning processes of software architecture.  These processes consider the higher levels of enterprise architecture (specifically the business and information architecture) to create To-Be Software Models of the entire (or relevant) software ecosystem.  If you’ve ever seen a wall chart illustrating two dozen or more software systems with connectors illustrating things like flow of data or dependencies, you’ve seen a model of the type I’m referring to.  Creating and updating these kinds of diagrams is a quarterly or semi-annual process and reflects the gradual changes in the strategy of the enterprise. 

    In the middle, you have the Balancing processes of software architecture.  These processes consider the needs of a single system but only from the level of deciding why the software will be divided up into modules, layers, and components, how that division of responsibility will occur, and what the resulting system will look like when deployed in specific technologies in a specific environment.  All of this can be conveyed in a fairly short document that is rich in diagrams with a small amount of text explaining the choices.  This occurs once when a system is moving forward, and the software architecture can be developed alongside the first couple of sprints as input to the third and subsequent sprints.

    At the bottom, you have the Realization processes of software architecture.  This is where the architecture becomes software, and this is where decisions are made about the choice of specific design patterns, the appropriate level of configurability vs. simplicity, and the ability to demonstrate whether the actual intent of the architecture occurs in practice.  In agile, this layer occurs within the team itself.  The software architect can offer advice about what patterns to use, but it is up to the team to realize that advice and/or decide not to implement it.  The team will very likely implement the software architecture as described, but may choose to improve upon it.

    What does the process look like

    There are many visualizations of scrum running around.  Some are described in books, others in papers or blog posts.  Most share some common elements.  There is a product backlog that, through the magic of sprint planning, the team extracts a subset for the sprint.  This becomes the sprint backlog.  The illustrations then tend to show the various rhythms of Sprint as cycles (sprint cycles and daily cycles), ending with a demonstration and retrospective.

    In order to illustrate and train a team on all elements, including the business analysis elements, we chose to be a bit more explicit about the steps PRIOR to sprint planning, including the processes of creating and improving the stories prior to the start of a sprint.  (as above, click on the image to enlarge it).

    image

    Astute observers will notice that we added a step that we are calling “pre-sprint story review.”  This is a meeting that occurs one week prior to the start of a sprint.  It is called by the product owner and he or she invites “senior chickens” (architects, user experience leads, development and test leads, and any other “non-team” members that want a say in the sprint. 

    In that week prior to sprint planning, those folks, working with the product owner, can improve the stories, add constraints, refine the description and acceptance criteria.  And here’s where the architects get to play.  Architects fulfilling the role of “Balancing” in the model above will have (or can create) an outline document describing the architecture of the software system, and can “link” that document to the SPECIFIC STORIES that are impacted by that design. 

    (Note: assuming you are using a tool like Microsoft’s Team Foundation Server, that fully enables Scrum in multiple forms, this is a nearly trivial activity since a document can be easily linked to any story.  Enough advertising.)

    So is an architect a chicken or a pig?  Answer: depends on what “layer” the architecture is at.  The top two layers are chickens.  The third layer, realization, is done by the team itself.  The person on the team may or may not have the title of “designer".  (I’d prefer that they did not, but that’s just because I believe that ALL team members should be trained to fulfill that role.  In reality, the skill may not be wide spread among team members).  Therefore, the third layer is done by the pigs. 

    I hope this provides some insight into how a team can embed software architecture into their scrum cycles.  As always, I’m interested in any feedback you may wish to share.

  • Inside Architecture

    A practical set of EA deliverables

    • 6 Comments

    A question on LinkedIn recently reminded me that, as the team leader for Segment Architecture in my former EA team, I was accountable for identifying a core set of deliverables for the team.  The idea was that we could focus on defining standard formats and contents for these deliverables and, in doing so, we could start to measure both our output and our quality.

    We only created  pre-canned templates for a few of them.  This is partly because the team was not mature enough in its practices to get consistency, and partly because Enterprise Architecture itself is not mature, or accepted, enough to have stakeholders that would notice if our deliverables meet an objective standard.  Also this list is not intended to be comprehensive.  The goal was to describe deliverables where it may possibly make sense to go for some level of consistency.  Any EA could (and often did) create deliverables that were not on the list.

    Perhaps it is time to share what we came up with. 

    Note that this list is the result of a single team doing its work, and is not representative of any “standards” effort across other EA groups.  That said, I stand beside this list.  I think it is a useful start.  Note that many are technical in nature.  I did not, in making this list, differentiate between BA and EITA deliverables.  So if you are someone who believes that EA = BA + EITA, then you will see both sets of deliverables, intermixed, in the list below.  If you are someone offended by the inclusion of technical architecture deliverables in an EA list… tough.  I was working with reality.

    Deliverable name

    Why create it

    Description

    Architectural Point of View (or Technical Policy)

    Provide clear input to Business or IT leadership on issues relevant to Enterprise Architecture

    Short document describing a problem that requires attention and the opinion of EA for solving it.

    Architectural Reference Model (or Architectural Pattern)

    Provide clear input to IT project SMEs on optimal or preferable design options

    Short document describing a set of concerns and a proven approach for addressing them

    <Segment> Current State Model and Analysis

    To demonstrate and communicate challenges inherent in current processes / systems / information

    A collection of architectural models, including a context model, process models, and information models, as understood to currently exist , plus an analysis of issues and risks

    <segment> Future State Vision and Model

    To demonstrate the design of the future processes / systems / information needed by strategic intent.

    A collection of architectural models that reflect a specific set of engineered changes

    Governance Model and Analysis

    Clarify roles and responsibilities and decision making processes for planning and oversight of initiatives

    Process model, description of roles and responsibilities, and description of deliverables needed for planning, oversight and governance, along with implementation ROI and plans

    M&A Business Case & Analysis

    To provide a rationale for the acquisition of a company for the purpose of improving operational effectiveness. (M&A)

    The document contains rationale including Competitive Analysis, SWOT / Twos analysis, and Strategic Alternatives Analysis

    System Integration Recommendations  Document

    To set a vision for how key processes and systems shall be integrated into enterprise infrastructure (primarily M&A)

    End to End business scenarios, Process and System Integration points, Risks and Issues for each integration concern, and an analysis of alternatives and recommendations

    Value chain and operating model analysis

    To clearly address gaps and strategic requirements for integrating or divesting a set of processes and/or systems (primarily M&A)

    Target value chain and operating model for post-M&A future state. Mappings of key processes to or from the enterprise core diagram, and analysis of changes with the intent of composing key initiatives.

    Enterprise Core Diagram

    To clearly declare the processes and systems that are NOT core to the operations of the enterprise

    A list of systems and processes mapped grouped into “ecosystems” that are clearly indicated as “core” and “edge” with analysis of governance

    EARB Engagement Package

    To demonstrate project level architectural quality to the EA Review Board

    A pre-defined collection of project architectural models and artifacts.

    Capability Model and Assessment

    Provide clear basis for data collection for a segment

    List of capabilities for a segment with assessment of capability maturity, etc.

    Capability Gap Analysis

    Highlight underperforming capabilities to focus investment

    Map of capabilities needed by strategies, highlighting those needed investment, and listing relative and absolute program spend against each

    <segment> Roadmap (a.k.a. Transition Plan)

    To clarify the scope, timing, and dependencies between initiatives needed to deliver on a strategy

    List of proposed initiatives and dependencies between them to deliver on strategic intent

    Strategy Map and/or Balanced Scorecard

    To clarify the strategies, goals, and objectives of a segment and allow for measurement and alignment

    Categorized strategies, measures, and metrics for a specific timeframe and business scope

    <segment> Process Model and Analysis

    To clarify and build consensus on the business processes (as-is or to-be), and as input to process improvement / measurement

    Models of processes, activities, information assets and system interaction points , and an analysis of opportunities to improve.

    Enterprise Scenario and Analysis

    To get clarity on the experience of a key stakeholder (often a customer or partner)

    Textual and diagrammatic description of an experience, often with analysis to indicate opportunities

    <segment> Information Model and Analysis

    To improve understanding of requirements and the rationalization of design

    Well-constructed information model, at one or more well-defined levels of abstraction, covering all aspects of a segment, aligned with EDM, along with an analysis of risks and issues

    Platform Assessment

    Capture ability of an app or platform to meet strategic needs

    Collection of measurements, attributes, and mappings to an app or platform

    Proof of Concept (POC) delivery

    To create a design that demonstrates, and proves, an approach for solving difficult issues

    A software deliverable and an architectural reference model (see above)

    Record of Architectural Tradeoffs

    To clearly communicate the tradeoffs made by architects on the customer’s behalf

    Textual description of architectural decisions and the implications for the owner of the process / tool

  • Inside Architecture

    The “Right” Representation of the EA Value Cycle

    • 4 Comments

    In the world of Enterprise Architecture, we are still creating “shared” understanding of how to tell our stakeholders what we do.  There is no consistency in our diagrams or our descriptions just yet.  This post will discuss the different ways we present the value stream of Enterprise Architecture and will attempt to select a particular viewpoint that can be useful for the majority of situations.

    First, let’s address the most commonly shared representation: TOGAF.  The TOGAF ADM model illustrates a sequence of activities that starts with a preliminary phase and works its way through each of the levels of architecture.  Basically, TOGAF illustrates a straight-through process from phase A through phase H to develop and use architecture. 

     image

    First off, I’m no huge fan of this illustration.  I always wondered how you get to an architectural vision prior to considering the architecture of the business.  Also, the notion of a center point focused around requirements management feels weirdly tactical.  At the level of an Enterprise Architect, I’m dealing with strategies and measures of success.  At the level of a technical architecture, the word “requirements” has an altogether different meaning.  Grouping together the notion of “strategic needs” with “technical requirements” may make sense to a technologist, but I don’t know a single business stakeholder of EA that would agree with grouping those two rather distinct things. 

    Who is our audience?

    These observations bring me to my first key consideration: If we want to communicate the value stream of Enterprise Architecture, we first should consider the audience, “who are we communicating to?”  If we are communicating to a stakeholder of EA, we should show them the bits of EA that are relevant to them, and we should not show them the bits that are not. 

    It is not cynical to gloss over the complex bits of EA when talking to a business stakeholder… it is practical.  In fact, we do it all the time.  If you buy cable TV services, a person from the cable company may come to your house and install a coax cable to your home.  He will mess around with a cable box for a few minutes, and then, if you are lucky, he will show you how to do simple things like changing channels and recording your favorite shows.  Then, he’s off.  He does NOT spend an hour describing the various technical aspects of signal transmission and digital carrier signals.  Why should he?  You don’t care.  You want to watch TV, not get a degree in electrical engineering.  And the same applies to EA.

    Secondly, if we want to communicate EA, let’s recognize that different people interact with Enterprise Architecture in different ways.  Business stakeholders will interact with Enterprise Architecture to ensure that their strategies are being executed effectively, with minimal interference, and producing a result that considers things like security, cost of ownership, and the ability to cope with rapid changes in the marketplace.

    Recap:

    1. We have to care who we are speaking to, and we have to reflect the things that they care about.
    2. We have to show them the details that matter to them and obscure the details that don’t.
    3. We should illustrate the activities in the context of the processes that they understand, and not at a conceptual level that may be difficult to relate to their daily experience.

     

    The ADM from TOGAF is an odd bird, because it attempts to be all things to all people.  It represents EA in a way that every stakeholder can use, but honestly, no stakeholder can use it.  It is not wrong.  Far from it.  But it is not useful because it violates every single one of the rules above.  The ADM reflects the EA viewpoint, but not the viewpoint of the customers of EA at a level that they can grasp, understand, and most importantly, use.  So let’s keep the ADM in our court, and create a view of the EA process that is relevant to our stakeholders.

    So who are our stakeholders?  For the sake of this post, I’m going to select one set of stakeholders and ignore the rest.  Is that correct?  Nope, but it is practical for a blog post.  What this means is that the rest of this post produces an answer of the “right” representation only for one class of stakeholders… another representation would likely be needed for different people.  That is the nature of EA.  Let’s not fret it.

    Stakeholders: Non-technologists

    There is a widely held view in Enterprise Architecture that an EA must be technically savvy in order to be effective.  There are certainly business architects who are quite effective who are not technologists, but in order to move UP to the notion of an EA (which includes business architecture, information architecture, solution or application architecture, AND technology architecture), you would need to be technically capable. 

    I won’t belabor the point about whether it is correct to view Business Architecture as a subset of Enterprise Architecture.  It is the wildly predominant view.  (A poll that I put on LinkedIn that asked this question found that well over 80% of EA respondents agree that EA generally includes every aspect of business architecture.  That’s pretty overwhelming.)

    That said, our biggest struggles in EA rarely involve conversations with other architects.  While there may be a great deal of confusion, there is rarely a lack of buy-in for architecture among architects, or even technologists.  Our key challenge, when it comes to communication, comes when we are talking to non-technologists.  In other words, the proverbial “business” stakeholders of EA.  (Please don’t flame me about whether IT is part of the business or not. That is a useful conversation, but it is outside the scope of this post).

    Therefore, for the rest of this post, I will focus on the non-technology stakeholders of Enterprise Architecture.  These are people whose chief concerns are not technical concerns.  We could say that they care about financial performance, role clarity, cycle time, cost effectiveness, market position, revenue growth, opportunity costs, business drivers, and many other factors outside the realm of technology concerns.  People in this category include senior business leaders (CEO, COO, CFO, CIO, CMO, etc), as well as business unit leaders (General Managers, Sales Division Leaders, Product Development and Marketing, Customer Service, Online Services, etc). 

    In order to communicate directly and well to these folks, lets recognize that they don’t care about the aspects of architecture that are technology focused.  While the WANT good technology, and will BENEFIT from good technology, they will assume that the technology issues can be handled effectively without bothering them with details.  To refer to our previous metaphor, they want the cable company to handle the technology, so that they can deal with changing channels.

    So, let’s take the ADM, and trim out the stuff that non technologists rely on, but don’t need to have a conversation about.  They assume it is there.  That includes the preliminary stage, as well as architectural vision, requirements management, information systems architecture, technology architecture, and architecture change management.

    The ADM now looks a bit different.  In fact, we can put it in a single row with a looping arrow.  Note that, in TOGAF, the Business architecture phase includes both current state assessment and future state modeling.

    image

    Representing the processes of the non-technical stakeholder

    We have removed the confusing bits from the view of the non-technical stakeholder, but it is tough to say that we are at the point where we are relevant.  After all, the non technical stakeholder has a business process that he uses when working with changes to his or her business.  We are not representing that process. 

    The process, frequently described in dozens of bits of EA literature, starts with an understanding of the current situation within the business.  Then, when the business creates a strategy, we bring these two bits of information together (current state and strategy) to create a vision for the future.  This is the order that the non technical stakeholder may recognize… not the generalized view of the ADM.  So it is time to break apart and rearrange the bits a little bit.  I will now step away from the “crop circles” representation since it is so far out of the experience of people who describe business processes.

    image

    In this view, we can begin to see the steps that an Enterprise Architect would perform that are visible to a non-technical stakeholder.  Just for the sake of clarity, this doesn’t mean that the technical steps are absent… it just means that our technical efforts don’t have to be paraded around in front of our non-technical stakeholders. 

    Note that I relabeled the ADM steps. 

    • Business Architecture becomes Current State Evaluation, and Strategy Development
    • Opportunities and Solutions becomes Future State Modeling
    • Migration Planning becomes Roadmap Development
    • Implementation Governance becomes two things: Funding and Initiation (the Project Portfolio Management aspects) and Oversight and Governance (the governance of ongoing activities).
    • Architecture Vision is cut down to only the elements relevant to the non-technical stakeholders: the evaluation of the current state of the enterprise.

     

    Let me point out that the TOGAF process assumes a different order of activities than the diagram above.  From the standpoint of the stakeholder, this is what makes sense, regardless of how TOGAF describes the stages.  This is why I’m no big fan of TOGAF as a methodology.  It doesn’t reflect reality.  On the other hand, the elements above are fairly well understood. 

    Also note that I’m not saying that the substitutions listed above are equivalent.  In fact, I’d argue violently that Business Architecture is far more than Current state evaluation and Strategy Development.  However, from the viewpoint of the non-architect, business architecture is a process that is involved with the development of business models (current and future), and that’s about it.  There is a great deal of effort that is not seen by the stakeholders.

    In other words, the blue model above is only showing the tip of the iceberg, and relabeling the phases according to what is (approximately) visible, not what is actually there. 

    This is an important part of explaining an activity to a stakeholder, and it is a skill that every Enterprise Architect must get good at.  You have to explain your activities in the context of what a stakeholder understand and recognizes… not in the context of all your work.  It’s not about you. It’s about the stakeholder.

     

    The Rules of Value Streams

    There are a few problems with the view above.  In order to understand the problems with that view, let’s mention a couple of rules for representing a value stream.  We will use these concepts because the ability to describe EA in terms of a value stream is important.  Value streams are sticky… they are easy to remember and easy to relate to.  If we want to remove the barriers to adoption of EA, we could do far worse than using this technique.  That said, there are some rules that we have to keep in mind:

    1. A value stream does not illustrate dependencies that are not really there.  Parallel efforts should be represented as parallel if that would improve understanding of how value is created.
       
    2. The value stream is illustrated as a sequence of high level processes in a straight line from left to right.  That said, a value stream must start with an event that is relevant to the customer who gets value.  It must end with the deliver of that value.  Any activity that is not part of that flow (from relevant starting point to value) should be represented “above” or “below” the value stream.  
       
    3. A value stream should be illustrated in its fully operational state.  In other words, it should describe a process that is running, not one that hasn’t been created yet.  Events that are relevant only for “start-up” activities can be included, but should not be the primary focus of a value stream.

     

    So let’s apply rule #1.  Is it true that the current state of the organization actually feeds the development of strategy?  No.  In fact, the evaluation of the current state can happen completely in parallel to the development of business strategy. 

    So the diagram could look like this one.

    image

    Here, we can see that there are, in fact, parallel activities for the understanding of the current state of the enterprise, and for the development of business strategy.  Where they first intersect is in the development of the future state (the opportunities and solutions phase from the ADM model).  You need both an understanding of the current situation and the needs of the future in order to describe where the organization should move towards. 

    Now, let’s apply rule #2.  What is the event that the business considers to be relevant to start the value stream of Enterprise Architecture?  The Development of Business Strategy, of course.  So the flow should perhaps look more like the diagram below… (note, the arrows and activities are identical to the one above… the only thing different is the order on the page).

    image

    Now, let’s apply rule #3… that one is easy.  The arrow at the bottom that says “First TIme EA” can simply be dropped.  After all, the first time a process is run, it starts from somewhere.  It is simply irrelevant to the non-technical stakeholder to point out where that starting position is. 

    Exception: if you run Enterprise Architecture as a consulting arrangement, you may want to leave that arrow in there.  After all, you will need to illustrate where the consulting arrangement will start.  That said, I have found that fewer and fewer EA initiatives begin with the hiring of a consulting firm. 

    Providing context

    When we started with the ADM, we assumed that there was a 700+ page methodology and framework behind the image, describing each step and what is included.  However, your stakeholder will not read the TOGAF or any other 700+ page body of information.  That would be absurd.  You need to add a little detail to the image to describe what is in each of these stages.

    It’s also a good idea to “clean up” the diagram a little so that we use less space on the “arrows and boxes” and more engagement on the ideas of what is going on.  So the next modification of the process looks like this:

    image

    This diagram is a better one for informing the non-technical stakeholders of your Enterprise Architecture program about what it is that you do.  We remove a little of the “accuracy” about where an arrow starts and ends, but we add a great deal of context about what is happening along the way.

    The “backward” arrow along the bottom clearly indicates that there are activities that flow outside the value stream but which are needed for each repeat of the cycle. 

    Final words

    Is this a perfect representation of the EA process?  I don’t believe in perfect things… just useful things.  But it is better, in my opinion, than showing a non-technical stakeholder the ADM or one of the “box and arrow” models above.  It uses the visual language of value streams and business process models, both widely recognized and used in business interactions.  It explains itself without going into a lot of detail.  And it clearly describes the end to end flow without restricting or dictating where Enterprise Architects start and stop (an important requirement, since maturing EA programs will change their scope as they mature).

    I have shown this view to others, and some have wondered about the “backward flowing” process along the  bottom.  The alternative to showing something as “backward flowing” would be to illustrate it as a cycle (with arrows feeding “in” from the right and “out” from the left).  If it is a challenge for you to view the diagram without those arrows, I apologize.  I’d love to see other view of this model that illustrate the “cycle” in a way that still meets the “rules of the value stream” as discussed above.

    I’d love to get feedback and insight from the community.  What do you think?  Does the last image above resonate?  What would you do differently?

  • Inside Architecture

    Accelerating Business Architecture

    • 6 Comments

    I have, on occasion, been asked to spend time with an Enterprise Architecture team to help that team improve their maturity.  It’s a great opportunity for me to learn, and share, and work with some of the smartest people on earth: Enterprise Architects.  Coming off of an excellent experience in Europe, I’d like to share some reflections.  I won’t name my client company to save them from any possible embarrassment. 

    This was a rather unusual case for me.  Typically, I’d do fairly simple things.  I may review and evaluate some activities, train folks for a day on methods, or perform a maturity analysis and provide a report out.  While each of these require expertise, none are particularly dynamic.  Nothing that would really push me to learn and adapt. Not so this time.

    In this case, an EA team, made up of mature, experienced architects, was being challenged by an hard-driving CIO to “climb the ladder” into a strategic role, and do it quickly.  Since the team was distributed around the world, climbing that ladder (which is already difficult to do) was made all the more challenging by the limitations of communication at a distance.  Each of the architects were peers, which meant consensus and a shared vision were critical.  They needed to accelerate their progress. 

    First, to be blunt, I’m not new at this.  I’ve conducted trainings and workshops in a wide array of places to a wide array of teams.  I’ve attended dozens of EA trainings and workshops.  I hold two EA certifications (and will soon have a third).    But this particular engagement was challenging.  It was challenging because the objectives were clear, ambitious, and very specific.  Due to the singular vision of one particular architect (who reads this blog… yes, I mean you, PH), I had a very clear set of marching orders: accelerate the team towards impactful and relevant business architecture.

    We held a series of exercises over two very full days in a beautiful country inn in Germany.  In each session, I provided some concepts and some practical tips from my own experience, followed by an exercise that got the group out of their chairs and collaborating in teams.  Over the course of those two days, the team decided, for itself,

    • what kind of Enterprise Architecture team they wanted to be,
    • what their vision and goals were,
    • what their specific enablers needed to be,
    • and developed four alternative candidate roadmaps to deliver on their goals.

     

    Along the way, we discussed and practiced skills in business architecture, stakeholder relevance, alignment, and roadmap creation.  In the follow-up day, we worked to create visual stories that can be used to “tell the story” of their transformation to their many stakeholders.

    Honestly, that’s a hard road.  In a typical EA team, that amount of work takes weeks on a fast track.  I didn’t have weeks.  I had two days.  So I had to dig deep.  Working from every one of the experiences I’ve had in Enterprise Architecture, and thining back on every workshop or seminars I’ve ever conducted or attended, I pulled together an approach that left very little room for deviation from those goals.  We worked HARD, and I can honestly say that I learned as much from this team as they learned from me.  I am so honored to have had the opportunity to work with them, and I honestly hope to have another opportunity someday.

    What, you might ask, would the trainer learn from a training session?  Not much, if I were a trainer and if this were a training session.  But I’m not and this wasn’t.  I’m an architect and architecture manager.  I’m an execution and alignment expert.  This was a team of mature, thoughtful, and expert architects, each with over two decades of architecture experience.  No, this was no training.  This was guided empowerment.

    When you work with people who are, in all rights, your peers, and you work to create something that you know is magnificently difficult to do, and you succeed, you learn.  I certainly did.  I deepened my respect for the talent and experience of passionate and empowered men and women.   I broadened my skills of consensus and execution under constraint.  I built unique connections upon the ideas and efforts of so many before me who generously gave their time and talent to help me to grow. 

    There are ways through the difficult and challenging obstacles that can make life difficult for business and enterprise architects.  There are solutions.  There are options.  There are opportunities.  It takes focus, dedication  and passion to bring them to light.  I was richly fortunate to have a chance to work with such a strong, vocal, and passionate team of people. 

    To sum this experience up, I’d like to share my recollection of the words of one of the attendees.  At the closing, we spoke in turn about what we learned during the workshop and what we wanted to say to end it.  One attendee shared this:

    When I came to this workshop, to be honest, my expectations were very low.  I had no faith that business architecture could achieve the goals that were being set for it.  I just didn’t see it.  Now, after these two days, I can see it.  I feel like I learned 20 years of experience in two days.  Thank you.

    You are welcome.

Page 4 of 106 (632 items) «23456»