Governance

An Integrated Electronic Health Record Needs Enterprise Architecture for Communicating Separation of Concerns

by

Achieving true progress in creating integrated AND interoperable electronic healthcare management and information systems is very much a real-world, current-day Enterprise Architecture (EA) challenge – and it starts with “separating the business and technical concerns” using standardized EA methods, vocabularies and reusable assets. The manner in which the challenges are communicated, in particular, would benefit all stakeholders and acquisition managers. 

The “Right” Representation of the EA Value Cycle

by

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?

Outsourcing: Beyond cheap labour

by

Skills, best practice and business alignment mean outsourcing is here to stay (First published in ComputerworldUK) Is the IT offshoring trend we have seen over the last few decades now beginning to reverse whereby outsourcers and their customers are beginning … Continue reading →

Launching an Enterprise Architecture Program within State, Local, Municipal Organizations

by

When
launching a formal EA program, Government organizations often begin by
socializing the overall benefits of EA and developing an EA Charter and
Plan.  However, while both of these are valuable, they are more useful
as part of after-the-fact documentation and communication plans.  Having
worked with a broad spectrum of state, local and municipal government organizations across the US and Canada, our team, Oracle’s Public Sector Enterprise Strategy Team (EST), has found
that the first and primary focus in launching an EA program should be
on how to meaningfully engage top business leaders and other
stakeholders to discover their needs, identify what would bring the most
value to the organization, and obtain their buy-in and support for EA
as a key enabler in helping the organization achieve its mission
objectives. 

Launching an Enterprise Architecture Program within State, Local, Municipal Organizations

by

By Gloria Chou

When launching a formal EA program, Government organizations often begin by socializing the overall benefits of EA and developing an EA Charter and Plan.  However, while both of these are valuable, they are more useful as part of after-the-fact documentation and communication plans.  Having worked with a broad spectrum of government organizations across the US and Canada, our team, Oracle’s Public Sector Enterprise Strategy Team (EST), has found that the first and primary focus in launching an EA program should be on how to meaningfully engage top business leaders and other stakeholders to discover their needs, identify what would bring the most value to the organization, and obtain their buy-in and support for EA as a key enabler in helping the organization achieve its mission objectives. 

Why is launching (or re-launching) and EA Program relevant in the government space today?  Although state and local agencies may have had an EA team for years, many are just getting started on formalizing their practice and creating awareness of the team’s capabilities and purpose within the organization as a whole – though some are in fact successfully delivering Agency-wide Enterprise Architecture value.  Additionally, while a majority of Federal agencies have necessarily had established EA programs for over a decade in response to Clinger Cohen mandates, some are beginning to reshape their programs as they perceive the need to go beyond checkmark/compliance-based EA and demonstrate additional value to their respective organizations.  Governmental budget pressures are increasing the scrutiny on all resource allocation and deployment such that EA programs must stay relevant and drive acknowledged and desired benefits or else risk being cut.

I believe discovery and dialogue with executive leadership about their goals, objectives, strategies, and current planning processes has to come first as, only after this is known, can the team understand what is particularly valuable to the specific organization.  Too many Government EA programs seek to provide generic value and benefits, such as standardization and integration, that, while good aims in and of themselves, are not necessarily prioritized by the organization nor sometimes even compatible with their operating model and culture.  As a case in point, when working with a very large municipality in the West, the EST began discussing EA with a new, forward-thinking CIO who had been three months into establishing an EA program to change the way IT was viewed across the organization.  We had an initial meeting with the lead EA and found that the new EA team had been doing the expected: technology architecture current state analysis and building IT standards documents.  After three months, the team was well on their way to spending another year or more on documentation!  The question we posed was, how does this change the way IT is viewed across the organization? The answer was clear, it didn’t.  Understanding specific needs, gaps, and opportunities that the executives care about is essential to ensure EA is relevant and focuses on what the business needs to successfully execute on its strategies.   

Based on this understanding of the organization’s priorities and what would bring the most value, the EA team should analyze what needs to be done and propose how they can be a part of the solution.  In the example of the large municipality mentioned above, the EST helped the organization’s EA team identify areas of opportunity to engage with business leaders across the organization and facilitate meetings to better understand strategies, goals, capabilities and high-level value streams.  By starting here, we were able to get the EA team on a path to make better decisions on where they would invest their time to provide the most value to the enterprise.  As a part of this, the team needs to assess their own capabilities and competencies as well as that of other teams within the organization against what is needed and propose options as to how they might best help the organization and what other changes might be needed to achieve the organization’s goals.  In actuality, an EA approach would help facilitate this analysis and assessment of how EA itself could benefit the organization.  The team should consider developing the vision for change as well as current state and future state views of operations, analyzing the gaps, and developing recommendations and a roadmap for the successful introduction of EA into the organization.

Only after the recommendations have been presented, vetted, and selected by leadership should the team document the EA purpose, application, and approach.  While this information can be captured in the EA Charter and Plan, it only represents a part of the needed content.  The rest, especially the plan, can only be developed after seeking input from other stakeholders in the organization.  Even though the executives have weighed in with their input, direction, and approval, it is still often difficult to get an EA initiative started because so many other stakeholders also need to be convinced of the value.  For example, LOB leaders, business managers, and functional SMEs all have to be convinced of the value of EA or else they will not allocate the time and resource required to participate in facilitated sessions and verify/validate the architecture.  Executives and LOB leaders are critical in setting the vision for the future and describing the general goals for operations as well as communicating their overall investment and technology strategies.  However, even if the executives and leaders buy-in, the lower levels also have to perceive value/benefit or else they will put in minimum effort when you really need them to be fully engaged to provide detail as to the reality of operations, challenge the status quo of how things are done today, and ultimately take ownership of the architecture and support the transition to the future state.  Without the business fully on board, the EA recommendations and transition look good on paper but will never be executed. 

Similarly, other stakeholders including Corporate Strategy, Portfolio Management, Project Management, Lean/Six Sigma, and IT also need to fully support EA as they are also critical in the development, execution, and enforcement of EA.  The stakeholders in these other disciplines sometimes feel that EA encroaches on what they do and do not understand why it is necessary.  For example, Lean/Six Sigma practitioners and some business analysts already have great relationships with the business and have already documented and analyzed processes such that they believe they have already “modeled the business” such that EA business architecture development and analysis is extraneous.  IT organizations often point to their UML diagrams, systems engineering drawings, and infrastructure server drawings and say that they are already doing EA.  In seeking buy-in from these other groups, it is very important to first seek to understand and acknowledge the current state of operations – existing skills, processes, and assets – before proposing a future state of how EA enhances/complements.  Formal stakeholder analysis and RASCIs can be helpful, but I believe an attitude of respect for what others do and a collaborative approach is also critical as there are many organizational change issues and related sensitivities associated with introducing EA as a discipline as with any other transformation.  Once general buy-in and support for EA is established, the disciplines need to work out details around overall processes, governance, timing, inputs and outputs to understand synergies, cooperation, etc.  Again, this is something that can be documented via EA, further decomposing views that were used in the overall analysis for the introduction of EA.

Big Issues Facing Business Technology in 2013 and Beyond

by

In these challenging times it is more than ever crucial to separate the real trends from fads and fashions and to be able to identify the big issues, business agendas and threats and opportunities shaping business in 2013 and beyond … Continue reading →

Big Issues Facing Business Technology in 2013 and Beyond

by

In these challenging times it is more than ever crucial to separate the real trends from fads and fashions and to be able to identify the big issues, business agendas and threats and opportunities shaping business in 2013 and beyond … Continue reading →

An Agile Enterprise Architecture (EA) Delivers Critical Business and Mission Agility

by

While working with a recent partner, the question came up; “What changes are made to the EA approach if agile methods are required, or otherwise heavily encouraged?” The initial answer at the time was “Not many – we already have an agile approach to EA embedded in our Oracle Enterprise Architecture Development Process (OADP), and our Oracle Enterprise Architecture Framework (OEAF) is independent of project management and project development approaches.”

Our OADP has always been agile and therefore supportive of business and government agility – particularly in the current context of severely constrained budgeting cycles. We firmly believe in a “just enough, just in time” philosophy, with collaborative insight and contribution across teams and leadership, and delivery of EA artifacts or guidance tuned directly to prioritized results. This means strategic, useful and reusable guidance modeled and delivered in a manner that supports both longer-term initiatives and near-term objectives.

EA delivered as an agile approach, however, does require continual line-of-sight traceability back to the IT investment strategy – which in turn is aligned to the business strategy.  

In other words, a Sprint Iteration approach might be justified (i.e. using the “Scrum” strategy), from all relevant perspectives, to quickly establish a reusable process and metadata model for a common agency function – like “Document Routing and Approval” (DRA). The output might be required to inform a software solicitation (i.e. to explain the requirements).  The output might be to establish a reference model and basic governance (business rules) for identifying and improving process efficiencies around the agency where DRA is occurring.

The actual need for this EA artifact (or “Product”, in Agile terms) may be driven from an unanticipated mandate or regulatory change, and therefore require rapid response.  The need may also be limited in scope to only a portion of the agency’s business (i.e. those who actually know they need it).

So, an EA Sprint will work, and deliver what’s needed quickly and effectively to the target audience.  The highest return on investment (ROI) in this exercise, however, only exists if actual Enterprise traceability and impact assessment occurs. In other words, an agile EA output with a strategic Enterprise outcome.

Note this is a common misunderstanding for Agile software development; Agile programming and project management may deliver useful, rapid and cost-effective “features” from a Backlog of priorities, but much of the supporting infrastructure, integrations and organizational change isn’t delivered using Agile methods, but must evolve in a more strategic, methodic manner.  Preferably with EA guidance.

Here’s what should happen.  The common DRA process, metamodel and business rules begin to shape, in a somewhat parochial “requirements-driven” context, heavily leveraging the impacted SMEs for a short period of time. As this occurs, the Enterprise Architect and stakeholders begin mapping and comparing the DRA process design (at appropriately coarse levels of abstraction) to any similar that may exist within the agency, or among agency partners or stakeholders.  This may require some additional outreach and communication.  The EA may find additional SMEs, risk factors, standards, COTS DRA solution accelerators, overlapping data management projects, etc. – essentially other activities or resources that can be used or might be impacted.

The Enterprise Architect is the Scrum Master!

Strategic oversight and influence is therefore brought to bear on the EA sprint, and by leveraging EA methods, the impacts to the rest of the organization plus any modifications to the focus EA artifact can be addressed – entirely within standard and expected IT Governance. The EA artifact development is a Sprint, but actually leverages our lifecycle methodology – from Business Context through Current and Future States, and then Roadmap (i.e. Transitional Architecture) and Governance.  The EA Sprint may actually kick off or modify a more holistic EA maintenance process.

We are therefore avoiding an “agile everything” philosophy, though we’re delivering agile results.   We contribute over-arching guidance and process for both the DRA project and the organization as a whole, to make sure that all projects underway are still aligned to meet the needs of the business and IT investment constraints.

This is essentially what we believe in applying our EA process, over time or during more Agile response cycles; always raise and maintain focus on the business strategy and drivers to guide the investment of IT budget into those areas that affect the business most – or that are the most immediate priority, such as described above.

Thanks to Oracle Public Sector Enterprise Architect Director Bryan Miller for contributing to this article!