On the road to a Business Architecture Manifesto

By |2016-09-28T22:42:34+00:00May 6th, 2012|Enterprise Architecture|

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

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

Should We Kill The Architecture Review Board?

By |2012-04-17T22:06:25+00:00April 17th, 2012|Enterprise Architecture|

OK… I’ll say it.  The whole idea of an Architecture Review Board may be wrong-headed.  That officially puts me at odds with industry standards like CobiT, ongoing practices in IT architecture, and a litany of senior leaders that I respect and admire.  So, why say it?  I have my reasons, which I will share here.

CobiT recommends an ARB?  Really?

The  CobiT governance framework requires that an IT team should create an IT Architecture board.  (PO3.5).  In addition, CobiT suggests that an IT division should create an IT Strategy Committee at the board level (PO4.2) and an IT Steering committee (PO4.3).  So what, you ask?

The first thing to note about these recommendations is that CobiT doesn’t normally answer the question “How.”  CobiT is a measurement and controls framework.  It sets a framework for defining and measuring performance.  Most of the advice is focused on “what” to look for, and not “how” to do it.  (There are a couple of other directive suggestions as well, but I’m focusing on these).

Yet, CobiT recommends three boards to exist in a governance model for IT.  Specifically, these three boards. 

But what is wrong with an ARB?

I have been a supporter of ARBs for years.  I led the charge to set up the IT ARB in MSIT and successfully got it up and running.  I’m involved in helping to set up a governance framework right now as we reorganize our IT division.  So why would I suggest that the ARB should be killed?

Because it is an Architecture board.  Architecture is not special.  Architecture is ONE of the many constraints that a project has to be aligned with.  Projects and Services have to deliver their value in a timely, secure, compliant, and cost effective manner.  Architecture has a voice in making that promise real.  But if we put architecture into an architecture board, and separate it from the “IT Steering Committee” which prioritizes the investments across IT, sets scope, approves budgets, and oversees delivery, then we are setting architecture up for failure.

Power follows the golden rule: the guy with the gold makes the rules.  If the IT Steering committee (to use the CobiT term) has the purse strings, then architecture, by definition, has no power.  If the ARB says “change your scope to address this architectural requirement,” they have to add the phrase “pretty please” at the end of the request.

So what should we do instead of an ARB?

The replacement: The IT Governance Board

I’m suggesting a different kind of model, based on the idea of an IT Governance Board.  The IT Governance Board is chaired by the CIO, like the IT Steering committee, but is a balanced board containing one person who represents each of the core areas of governance: Strategic Alignment, Value Delivery, Resource Management, Risk Management, and Performance Measurement.  Under the IT Governance Board are two, or three, or four, “working committees” that review program concerns from any of a number of perspectives.  Those perspectives are aligned to IT Goals, so the number of working committees will vary from one organization to the next.

The key here is that escalation to the “IT Governance Board” means a simultaneous review of the project by any number of working committees, but the decisions are ALL made at the IT Governance Board level.  The ARB decides nothing.  It recommends.  (that’s normal).  But the IT Steering committee goes away as well, to be replaced by a IT Steering committee that also decides nothing.  It recommends.  Both of these former boards become working committees.  You can also have a Security and Risk committee, and even a Customer Experience committee.  You can have as many as you need, because Escalation to One is Escalation to All.

The IT Governance board is not the same as the CIO and his or her direct reports.  Typically IT functions can be organized into many different structures.  Some are functional (a development leader, an operations leader, an engagement leader, a support leader, etc.).  Others are business relationship focused (with a leader supporting one area of the business and another leader supporting a different area of the business, etc.).  In MSIT, it is process focused (with each leader supporting a section of the value chain).  Regardless, it would be a rare CIO who could afford to set up his leadership team to follow the exact same structure as needed to create a balanced governance model.

In fact, the CIO doesn’t have to actually sit on the IT Governance board.  It is quite possible for this board to be a series of delegates, one for each of the core governance areas, that are trusted by the CIO and his or her leadership team. 

Decisions by the IT Governance board can, of course, be escalated for review (and override) by a steering committee that is business-led.  CobiT calls this the IT Strategy Committee and that board is chaired by the CEO with the CIO responsible.  That effectively SKIPS the CIO’s own leadership team when making governance decisions.

And that is valuable because, honestly, business benefits from architecture.  IT often doesn’t.

So let’s consider the idea that maybe, just maybe, the whole idea of an ARB is flawed.  Architecture is a cross-cutting concern.  It exists in all areas.  But when the final decision is made, it should be made by a balanced board that cares about each of the areas that architecture impacts… not in a fight between the guys with the vision and the guys with the money.  Money will win, every time.

Analysis, Synthesis, and Scope: Business Architecture vs. Business Analysis, part two

By |2012-04-08T16:05:51+00:00April 8th, 2012|Enterprise Architecture|

A few days ago, I quickly dashed off a post on the difference between a business architect and a business analyst.  The reaction was immediate and rather vociferous.  The IIBA took me to task for saying that a business architect is NOT a business analyst.  In addition, Tom Graves (Enterprise Architect) asked me to consider the possibility that the two roles are primarily different in another way, altogether.  Tom asked me to consider the possibility that an architect role is primarily one of synthesis (putting things together), while an analyst role is one of analysis (taking things apart).  I beg to differ.  This post included my thoughts on that distinction.

Graves’ trilogy: Analyst-Anarchist-Architect

Tom has pointed out, in past articles, that there is real value for enterprise architects to consider the Hegelian triad of Thesis-Antithesis-Synthesis.  In his post, Tom presents a triad, based on Hegelian thinking, three different roles in sequence: business analyst – business anarchist – enterprise architect.

In Tom’s thinking, the analyst is good at creating an initial hypothesis that represents incremental improvement… at doing things right.  The anarchist is the role that questions the assumptions underlying the analysis.  It is the role of anarchist to test those assumptions, and make sure that they do indeed align with the real world of “trial, error and experience”.  The anarchist prevents us from accepting our assumptions.  The architect puts it all back together.  According to Tom Graves:

And the architect role is about bringing it all together again. It’s the ‘synthesis’ part of the triad; but it’s also about the Concrete, about making things real, being effective – about doing the right things right in a concrete, practical way.

Here is where I have to take my hat off to Tom.  There is a very important thought process going on here, and one that I both agree with and can immediately use.  I admit to not having taken the time to really grok Tom’s post prior to now, but I couldn’t agree more with the thinking process.  You have to form an initial idea, then break apart the assumptions in order to test the initial idea, and lastly bring it all together in a solution that actually works.  It’s an excellent approach.

Shouldn’t this kind of thinking simply be a template for each individual person?  Shouldn’t one person perform all three activities?  Tom addresses this as well.

One way to resolve the architecture of that architecture is to have just one person doing all of those roles – after all, they’re different roles, not necessarily different people. But that can sometimes be quite a ‘big ask’, because each of the roles does demand different skillsets, different paradigms, even different worldviews – again, somewhat tricky.

Tom suggests that it is difficult for one person to perform all three, and that large organizations (and large markets) may have the freedom to separate out the roles into different people.  It’s an interesting idea, but I don’t know if provides the clarity I’m looking for.

I believe that Tom is completely right in one respect.  Solving a problem effectively requires that you go through stages of thinking.  If you simply look at the problem and conceive of a couple possible solutions, you could just as easily fail to consider the optimum one (not on the list), or choose the wrong solution (whatever “wrong” means).  In order to reach the best possible decision, you must go through the additional steps of antithesis and synthesis. However, I don’t think that this distinction is sufficient to explain and position the roles of Business Analyst and Business Architect. 

The process of thinking through a problem applies to ALL roles that solve problems (a fairly long list).  It doesn’t just apply to business analysis.  Following the path from thesis to antithesis to synthesis is an art practiced by artisans, craftsmen, mathematicians, scientists, engineers, leaders, managers, and politicians.  It is best practice for all of human thought, and not just one area of human endeavor.  Everyone who thinks, and considers, and solves, should use all three steps.  To use Tom’s terminology, each person should be an analyst, an anarchist, and an architect.

Different Efforts, Different Results

Tom’s thought process is excellent, but I don’t believe it answers the core question.  Over the past few years, we’ve seen the emergence of two different “job titles.”  Both jobs emerged out of the need for the information technology division to address business problems in new and novel ways.  The core question that I’d like to address is simple: is this something that one person does, or something that two people do?  Are we more effective, and efficient, to separate the roles and responsibilities?

Some things we all agree on.  The business analyst role is much more tactical than the business architecture role.  Traditionally, the business analyst is required to understand the problems of a business area and to document the requirements of the business in solving them.  The business analyst is NOT accountable for developing the solution, or even the vision for the solution (The solution architect does that).  He or she is accountable for understanding the problem and documenting the requirements that the solution must meet.

The business architect role is a more recent innovation.  This role emerged out of the need to insure that departments and divisions are using IT resources correctly by asking for the right problems to be solved.  From there, the role has expanded to a non-IT-focused value proposition.  The business architecture role is important.  Without the business architect involved, we may do an excellent job of solving problems that the overall enterprise does not need solved, when the real enterprise-level problems are going unaddressed or under-resourced due to the long list of demands from the existing businesses.

The business architect is different from the business analyst because he or she is fundamentally charged with four different responsibilities:

  1. understanding the actual enterprise-level needs and the relationship between one business area in respect to the overall strategies,
  2. partitioning the services that one business area should produce and the needed level of maturity for those services,
  3. creating a vision of those services, from the perspective of the business, and
  4. insuring that it aligns to the actual and proposed architecture of the business as a whole. 

Note that (2) occurs rarely… only when major changes to the business models themselves occur. 

Some analysis will perform responsibilities (1) and skip to (3).  In most cases, that works.  On the other hand, performing responsibilities (2) and (4) requires the skills of an architect.  There are two different skill sets here.  Can one person do both?  Yes.  Should they?  That depends.

As these roles continue to mature, we need to either carve out distinctions, or merge them into a single role. 

Business Analyst and Business Architect as one person

In my prior post, I made the case that there are many differences between a business analyst and a business architect.  My pr
ior post was based on the assumption that there needs to be two different people playing these roles.  That assumption is NOT valid in all cases. 

There are many situations where it makes a great deal of sense for the activities of business architecture and business analysis to be performed by ONE individual for financial and logistical reasons.  For example, if the IT unit in question has a small set of responsibilities, or if we are talking about a medium-to-small business (or business area), there just isn’t enough work to keep two different people employed full time in complementary roles.  Within my company (Microsoft), there are some smaller areas of the business that are covered by one individual who performs both business architecture and business analysis tasks.

The question that I have, however, is simple.  While it is possible for one person to perform two jobs, does that mean there SHOULD be one job?  Should we merge the roles so that every business analyst should be an architect, and every business architect should be an analyst?

Business Analyst and Business Architect as complementary roles

Regardless of what we want to happen, reality is going to keep getting in the way.  Both roles exist.  Sometimes they intersect.  The real challenge comes when two people have to play complementary roles, one as a business architect, and the other as a business analyst.  In larger organizations where business architects are appearing as independent roles, and in situations where consultants are being hired, this situation is increasingly common. 

In order to be effective, these two folks need to have clear accountabilities.  They need to be clearly supporting the success of one another, but able to succeed independently of one another (the failure of one cannot prevent the success of the other).  In order to meet these criteria, there is one very important distinction.  Both must have a different set of problems to solve, and both must have the full scope to solve those problems.  Both must perform the three steps of emergent thought that Tom points out: thesis, antithesis, and synthesis… or analyst, anarchist, and architect. 

There is no good source, in existence, for clarifying those accountabilities.  The Business Analysis BOK focuses on skills and methods, not accountabilities.  The Business Architecture BOK focuses on different skills and methods, but not accountabilities.  Both fields seem happy to simply overlap.  That is probably OK from the perspective of describing the fields.

However, in an actual organization, where people have jobs to do, more clarity is required.


No matter how we reconcile these two roles, we need to understand that the growth of business architecture will not be abated just because the profession of business analyst has laid a moral claim to the activities that business architects have decided to focus on.  Rather than argue about whether business architects are, first and foremost, analysts, lets look at whether we can address two key questions:

a) Is it better or worse for these roles to be independent?

b) When both roles exist in the same organization, how do we prevent confusion, clarify accountabilities, and make both roles effective?

Arguments don’t matter.  Answering these questions… that matters.

The difference between business architect and business analyst

By |2012-04-06T12:18:00+00:00April 6th, 2012|Enterprise Architecture|

[Author’s note: within an hour of posting the following article, Kevin Brennen of the IIBA dry-roasted the post on his own blog.  You can find a link to his entry here: Business Architecture is Business Analysis.  I have made an attempt to fix a few of the most egregious errors in the post, and to follow up with an addendum (below).]

One distinction that I believe we should make, as the field of business architect takes hold, is the difference between a business architect and a business analyst.  There are real opportunities for confusion here.  In addition, there are some folks who believe that there is a good career growth path from business analyst to business architect.  In this post, I will provide my opinions about the relationship.


Business Architect – A role within various types of enterprises (business, government, non-profit) that is focused on collecting information on the strategic positioning of an area of activity (line of business, business unit, department, team, etc.) and creating a clear picture of the capability gaps that may impede that area from reaching it’s full and required potential.

Business Analyst – A role either within an information technology division of an enterprise, or within a non-IT team serving as a key point of contact with an IT division.  This role is focused on understanding the root cause of a specific business problem in order to develop the IT requirements needed to address that problem.

(Inevitably, someone will ask me where I got those definitions.  I made them up.  I reserve the right to be wrong.)


Both of these fields analyze the business… but that is where their similarities end.  Let me repeat that: Business Architects analyze the business.  Business analysts analyze the business.  

  Business Architect Business Analyst
Why To uncover the gaps between strategic needs of a business unit, and their abilities to meet those needs, and to charter initiatives to fill those gaps. To develop and document the detailed knowledge of a business problem that an initiative has been chartered to address.
How Analysis of future-looking strategies, capturing of capabilities, and modeling of inter- and intra- business relationships needed to discover the key capability gaps that a business must be prepared to face, along with the development of cross-functional roadmaps to address them.  System requirements are NOT captured. Interviews with existing business stakeholders and SMEs to elicit business rules, understand processes, information, and systems in use, and detailing the consequences (intentional or not) of making a business change to address a specific issue.  The primary result of this activity is the document of System Requirements.
When Ongoing process that is triggered by periodic strategy cycles within a business As-needed activity that is triggered AFTER a problem has been identified and requirements for a solution are needed.
Who Business or IT Generalists with a strong understanding of business functional issues, interdependencies, and business structural concerns.  Must be excellent at capability analysis.  Must leverage modeling and rigorous analysis skills. Business or IT Generalists with a strong understanding of information and application interdependencies, requirements analysis, and system development methodologies.  Must be excellent at IT requirements elicitation.  Must leverage modeling and rigorous analysis skills.
What Business motivational models, Value Streams, Scenarios, Capability models, Heat Maps, Funding Maps, Risk maps Business Requirements, Business Rules, Use Cases, and Detailed Business Process descriptions


Perhaps this simple table will do a good job of explaining why these roles are different.  If you look at the people and their skills, there is some overlap.  Certainly, smart people with excellent analysis skills can do many things.  But we are not talking about the people.  We are talking about the actual role.  There is nearly nothing about these roles that are actually the same.    These are fundamentally different roles.  Yes, there are people who can play both roles.  (One of the software developers I hired at Acadio had a degree in archeology.) 

In fact, I have never seen a business analyst successfully transition to the role of business architect.  Note that this is my personal experience, and I am willing to consider that there are many folks who have made that transition.  I have watched many struggle, and fail, on that road.  Given what I’ve seen, I consider this a very difficult transition.

I am not going to make a lot of friends with this post.  I respect that.  Just sharing my opinion and my experience.  Hopefully, I haven’t lost friends along the way.

[Follow-up note from Nick: I have met Kevin as well, and I respect the work that he has done, especially on the BABOK.  His blog post responding to this one was not a big surprise in hindsight.  However, I hadn’t expected such a complete rejection of the points.  So I took a few minutes to review the BABOK v2 document.  I hadn’t noticed this aspect of the guide before… guess I hadn’t been motivated enough to think about it: the BABOK defines the tasks of Business Analysis, not the role of Business Analyst. 

To whit, the BABOK v2 specifically states:

“A business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be. Business analysis practitioners include not only people with the job title of business analyst, but may also include business systems analysts, systems analysts, requirements engineers, process analysts, product managers, product owners, enterprise analysts, business architects, management consultants, or any other person who performs the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design.”

That is a very expansive definition. 

Let’s put in a terms of a metaphor.  What if the role of “physician” were defined in the same way.  Would it look like this?

A physician is any person who performs the activities of diagnoses, treatment, surgery, prescription, pharmaceutical distribution, wellness evaluation, or their related activities.  Physicians may include not only people with the job title of physician but also registered nurse, nursing assistant, pharmacist, pharmacy technician, physical therapist, physician’s assistant, psychiatrist, psychologist, chiropractor, personal trainer, and massage therapist or any other person who performs the tasks described in the Physician’s Desk Reference.

Do you see the problem?  The BABOK itself points out one of the key reasons for defining the profession: to define “the skills and knowledge that people who work with and employ business analysts should expect a skilled practitioner to demonstrate.”  How can an employer expect a specific level of skill if it that bar is so low that a dozen different roles are expected to perform it well? 

This is a problem with the BABOK, not the analysts themselves.  Including such a wide array of roles in the “definition” of a business analyst creates a situation where no other profession can define a role that cares about similar concerns without overlapping with this definition.  According to this definition, I’ve been a business analyst for 20 years. In fact, I stopped playing the role of business analyst over a decade ago. 

Here’s a simple test to see if you are a Business Analyst or something else:  if your employer decides to completely erase his IT budget, and spend NOTHING NEW on IT systems, how busy would you be?  If you answer “I’d go to part time” then you are sitting squarely on the line between business analyst and some other role. If you answered “I’m out of work,” then you are a full time business analyst.]

Time-to-Release – the missing System Quality Attribute

By |2012-03-09T01:26:25+00:00March 9th, 2012|Enterprise Architecture|

I’ve been looking at different ways to implement the ATAM method these past few weeks.  Why?  Because I’m looking at different ways to evaluate software architecture and I’m a fan of the ATAM method pioneered at the Software Engineering Institute at Carnegie Mellon University.  Along the way, I’ve realized that there is a flaw that seems difficult to address. 

Different lists of criteria

The ATAM method is not a difficult thing to understand.  At it’s core, it is quite simple: create a list of “quality attributes” and sort them into order, highest to lowest, for the priority that the business wants.  Get the business stakeholders to sign off.  Then evaluate the ability of the architecture to perform according to that priority.  An architecture that places a high priority on Throughput and a low priority on Robustness may look quite different from an architecture that places a high priority on Robustness and a low priority on Throughput.

So where do we get these lists of attributes?

A couple of years ago, my colleague Gabriel Morgan posted a good article on his blog called “Implementing System Quality Attributes.”  I’ve referred to it from time to time myself, just to get remind myself of a good core set of System Quality Attributes that we could use for evaluating system-level architecture as is required by the ATAM method.  Gabriel got his list of attributes from “Software Requirements” by Karl Wiegers

Of course, there are other possible lists of attributes.  The ISO defined a set of system quality attributes in the standard ISO 25010 and ISO 25012.  They use different terms.  Instead of System Quality Attributes, there are three high level “quality models” each of which present “quality characteristics.”  For each quality characteristic, there are different quality metrics.

Both the list of attributes from Wiegers, and the list of “quality characteristics” from the ISO are missing a key point… “Time to release” (or time to market).

The missing criteria

One of the old sayings from the early days of Microsoft is: “Ship date is a feature of the product.”  The intent of this statement is fairly simple: you can only fit a certain number of features into a product in a specific period of time.  If your time is shorter, the number of features is shorter. 

I’d like to suggest that the need to ship your software on a schedule may be more important than some of the quality attributes as well.  In other words, “time-to-release” needs to be on the list of system quality attributes, prioritized with the other attributes.

How is that quality?

I kind of expect to get flamed for making the suggestion that “time to release” should be on the list, prioritized with the likes of reliability, reusability, portability, and security.  After all, shouldn’t we measure the quality of the product independently of the date on which it ships? 

In a perfect world, perhaps.  But look at the method that ATAM proposes.  The method suggests that we should created a stack-ranked list of quality attributes and get the business to sign off.  In other words, the business has to decide whether “Flexibility” is more, or less, important than “Maintainability.”  Try explaining the difference to your business customer!  I can’t. 

However, if we create a list of attributes and put “Time to Release” on the list, we are empowering the development team in a critical way.  We are empowering them to MISS their deadlines of there is a quality attribute that is higher on the list that needs attention. 

For example: let’s say that your business wants you to implement an eCommerce solution.  In eCommerce, security is very important.  Not only can the credit card companies shut you down if you don’t meet strict PCI compliance requirements, but your reputation can be torpedoed if a hacker gets access to your customer’s credit card data and uses that information for identity theft.  Security matters.  In fact, I’d say that security matters more than “going live” does. 

So your priority may be, in this example:

  • Security,
  • Usability,
  • Time-to-Release,
  • Flexibility,
  • Reliability,
  • Scalability,
  • Performance,
  • Maintainability,
  • Testability, and
  • Interoperability.

This means that the business is saying something very specific: “if you cannot get security or usability right, we’d rather you delay the release than ship something that is not secure or not usable.  On the other hand, if the code is not particularly maintainable, we will ship anyway.”

Now, that’s something I can sink my teeth into.  Basically, the “Time to Release” attribute is a dividing line.  Everything above the line is critical to quality.  Everything below the line is good practice.

As an architect sitting in the “reviewer’s chair,” I cannot imagine a more important dividing line than this one.  Not only can I tell if an architecture is any good based on the criteria that rises “above” the line, but I can also argue that the business is taking an unacceptable sacrifice for any attribute that actually falls “below” the line.

So, when you are considering the different ways to stack-rank the quality attributes, consider adding the attribute of “time to release” into the list.  It may offer insight into the mind, and expectations, of your customer and improve your odds of success.

How Enterprise Architects can cope with Opportunistic Failure

By |2012-03-05T12:53:50+00:00March 5th, 2012|Enterprise Architecture|

You may not think that Failure is a desired outcome, and on the surface, there are some negative connotations to failure.  It just sounds “bad” for a team to fail.  However, there are times when a manager will INTENTIONALLY fail in a goal.  Let’s look at the scenario where a manager may choose to fail, and see whether EA has a role in either preventing that failure, or facilitating it.

What is Opportunistic Failure?

Does your organization manage by objectives and scorecards?  Scorecards and metrics are frequently used management tools, especially in medium and large organizations.  In a Manage-By-Objective (MBO) organization, a senior leader is not told “how” to do something, but rather a negotiation takes places that results in the development of a measurable objective.  The term “measurable objective,” used here, is a well-defined idea.  It is specific, measurable, actionable, realistic, and time-bound (SMART).  A measurable objective is a description of the results that a senior manager is expected to achieve.  In BMM terms, the objective is the “ends” while the senior leader is expected to figure out the “means.”  In business architecture parlance, the objective describes the “what” while the senior leader is expected to figure out the “how.”

Now, in many situations, a senior leader has to rely on other groups to perform, in some way, in order for him to achieve his measurable objectives.  This is quite common.  In fact, I’d say that the vast majority of senior-level objectives require some kind of collaboration between his or her people, and the people who work in other parts of the organization (or other organizations). 

For a small percentage of those dependencies, there may be competition between the senior leader’s organization and some other group, and that is where opportunistic failure comes in.

The scenario works like this: 

Senior leader has an empowered team.  They can deliver on 30 capabilities.  Someone from outside his or her organization, perhaps an enterprise architect, points out that one of those capabilities is overlapping.  Let’s say it is the “Product Shipment Tracking” capability.  The EA instructs the senior leader to “take a dependency” on another department (logistics in this case) for that.  The senior leader disagrees in principle because he has people who do a good job of that capability, and he doesn’t want to take the dependency.  However, he cannot convince other leaders that he should continue to perform the “product shipment tracking” capability in his own team. 

So he contacts the other department (logistics) and sets up an intentionally dysfunctional relationship.  After some time, the relationship fails.  Senior leader goes to his manager and says “we tried that, and it didn’t work, so I’m going to do it my way.”  No one objects, and his team gets to keep the capability.

In effect, the senior leader felt it was in her own best interest to fight the rationale for “taking a dependency,” but instead of fighting head-on, s/he pretends to cooperate, sabotages the relationship, and then gets the desired result when the effort fails.  This is called “opportunistic failure.” 

Thoughts on Opportunistic Failure

Opportunistic failure may work in the favor of anyone, even an Enterprise Architect.  However, as an EA, I’ve most often seen it used by business leaders to insure that they are NOT going to be asked to comply with the advice of Enterprise Architecture, even when it makes sense from an organizational and/or financial standpoint. 

In addition, one of the basic assumptions of EA is that we can apply a small amount of pressure to key points of change to induce large impacts.  That assumption collapses in the face of opportunistic failure.  Organizations can be very resistant to change, and this is one of the ways in which that resistance manifests. 

Therefore, while EA could benefit from EA, I’ll primarily discuss ways to address the potential for a business leader to use operational failure to work against the best interests of the enterprise.

  1. Get senior visibility. – If a business leader is tempted to use opportunistic failure to resist good advice, get someone who is two or more levels higher than that leader to buy in to the recommended approach.  This radically reduces the possibility that the business leader will take the risk to his or her career that this kind of failure may pose.
  2. Get the underlying managers in that senior manager’s team on board, and even better, get them to agree to the specific measures of progress that demonstrate success.  This creates a kind of “organizational momentum” that even senior leaders have a difficult time resisting.
  3. Work to insure that EA maintains a good relationship with the business party that will come up short if the initiative does fail.  That way, they feel that you’ve remained on their side, and will call on you to escalate the issue if it arises.
  4. Play the game – look for things to trade off with.  If the senior manager is willing to risk opportunistic failure, you may be able to swing them over to supporting the initiative if you can trade off something else that they want… perhaps letting another, less important, concern slide for a year.  



For non-EAs reading this post: EA is not always political… but sometimes it is.  Failing to recognize the politics will make you into an ineffective EA.  On the other hand, being prepared for the politics will not make you effective either… it will just remove an obstacle to effectiveness. 

MSBI–Part 2—What is a core diagram?

By |2012-02-14T07:40:00+00:00February 14th, 2012|Enterprise Architecture|

In her wildly popular book, Enterprise Architecture As Strategy, Dr. Jeanne Ross describes the use of “core diagrams” in Enterprise Architecture.  Shortly after introducing the notion of “operating models”, she provided four example “core diagrams” from successful companies and noted that each diagram reflected the specific challenges that companies with similar operating models would face.

This section of the book is often overlooked, but personally, I think Ross hit on something very powerful.  I spend a good bit of time speaking with CIOs and CTOs about Enterprise Architecture, and I am frequently asked a seemingly simple question: what does an enterprise architecture look like?  What is the “single picture on top?”  You’d think we could answer this question!  But until this book was published, there was no notion of what the “single model on top” should look like, or why one model would sit atop another.   This series of blog posts attempts to answer that question.

If this is the first post you are reading on this topic, you have started in the middle.  Go back to this article for the overview and table of links to the rest of the posts.

What is a core diagram?

A core diagram is an Enterprise Architecture model that reflects the level of integration and standardization that the company has chosen to embark upon, boiled down to specific, tangible, elements for business and technology professionals to discuss and agree upon. 

These two dimensions: process integration and process standardization, are the two independent variables that drive the selection of an organizations operating model.  This distinction is so important to the Enterprise Architecture itself that Dr. Ross defines the concept of “Enterprise Architecture” in these terms!  According to the book, Enterprise Architecture is: “The organizing logic for business processes, data, and technology reflecting the integration and standardization requirements of the firm’s operating model.”

Going beyond the book, this post will describe the concept and value proposition of a core diagram, while the next post will describe the business scenarios in which a core diagram can be valuable.  Between these two posts, I hope to clarify the reason why your EA program should create a core diagram.

The value of a core diagram

A core diagram is a very useful EA artifact for many scenarios.  A core diagram removes ambiguity that business stakeholders either suffer from, or take advantage of, when dealing driving change in the organization.  You can provide direct EA value by removing that ambiguity, presenting clear ownership, and addressing the occasionally emotional attachment that business and IT stakeholders have to overly complex implementations.

  • The core diagram illustrates processes that must be standardized.  Depending on your operating model, some subset of business processes (from a small subset in diversification companies to a large subset in unification companies) are standardized.  The challenge comes “on the line” where there is a case to be made on both sides of the debate: e.g. “this process can be valuable by being non-standardized.”  Assuming that you have a process owner who can decide one way or the other, a core diagram can help make that decision stick.  By clearly denoting a process as “standard” or “agile” in the core diagram, the decision can be clearly communicated and ownership clearly enforced.
  • The core diagram illustrates which data facets must be managed as “master data.”  Operating models with high levels of integration will have some number of shared data facets that are available across the enterprise (in a secure fashion, of course).  Which data facets depends on your company and your level of integration.  Clarity about which facets are shared, and which facets are NOT shared, is necessary for a simple and clear set of information sharing processes. 
  • The core diagram illustrates which systems will stand as “systems of record” for the management of specific functions.  Operating models with either high levels of integration or high levels of standardization will need to denote specific systems as being the “source of truth” for master data and the “system of record” for support of standardized activities.  Clarity removes the temptation to “build your own shadow application” or to “build for one silo” (two antipatterns in highly integrated environments).


A core diagram specifically supports the mitigation of these anti-patterns:

  • If we build it, they will come. (Anti-pattern)
  • I am different, so I need a different process (Anti-pattern)
  • It is too much of a hassle for me to share my data with you. (Anti-pattern)


It goes without saying that a core diagram is not sufficient, by itself, to eradicate bad behavior.  It is NOT a silver bullet.  In addition, there are examples of companies that have succeeded in creating a mature Enterprise Architecture program without one. 

That said, I asked Jeanne Ross about the value of a core diagram and this is what she told me:

“For most companies, I think some kind of picture is essential for understanding the expectations for a business transformation. It helps management understand to what extent everyone is on the same page—prior to drawing the diagram, they think they all mean the same thing, but they usually don’t.”

Jeanne Ross
Director and Principal Research Scientist
MIT Center for Information Systems Research

Personally, I believe that a core diagram is an essential part of most EA programs.  If you think it would be difficult to create a core diagram, your company is probably one that most needs one.

What are the criteria for a core diagram

A core diagram is not “just any EA model.”  It has a specific purpose and a specific part to play in the development of an EA.  It does not have a specific look and feel, although some suggestions for good visualization can be found the “Enterprise Architecture As Strategy” book.

You will know you have a core diagram when it meets all of these criteria:

  1. It is a single diagram with a clear scope representing either the entire enterprise or a specific independent business segment.
  2. The diagram reflects the difficult choices that were derived (or will be derived) from the selection of the company’s operating model(s). 
  3. A non-architect stakeholder can understand and use the model with less than thirty minutes of discussion.

Note that a core diagram is normally a “future state” model of the enterprise, reflecting the direction that the company should go.  However, this is not a requirement.  A current state core diagram could be created, as long as the compromises reflected within don’t make the diagram too complex for it to be simply understood.

Next up: Scenarios for the use of a core diagram (this link will be updated when the next entry is posted).

Creating a Core Diagram for Agile Business

By |2012-01-31T16:47:00+00:00January 31st, 2012|Enterprise Architecture|

Today, I gave my talk at the Open Group conference that presents a step-by-step method for creating a core diagram that is useful for agile business.  I will blog a series of posts on the topic to share this information to my friends and colleagues on the web.

I will create the following posts.  As I do, I will come back and edit this post to provide a link.  This post will stand as an introduction and table of contents to the topic. 

I will post the following articles:


This will likely take a few days, and I’d like to take a few minutes to describe each of these topics.  The talk lasted 45 minutes (at a wildly accelerated pace).  I plan to provide a better, albeit slower, set of information for the folks who read this blog.


Nick Malik speaking at the Open Group conference, Jan 31, 2012, San Francisco

If you’d like to see the original presentation, see the following slideshare presentation:

Do you address the complaint, address the root cause, or both?

By |2012-01-13T14:34:29+00:00January 13th, 2012|Enterprise Architecture|

Imagine a future where robots run the hospitals as a way to cut health care costs.  A robot ambulance pulls up to the door of the Emergency Room with an unconscious patient.  The robot triage nurse connects electrodes to the patient and notices a low heart rate, low blood pressure, and intense pain readings emanating from the abdomen.  The diagnosis: blood loss and pain.  Prescription: provide blood and pain killers. 

Then, in comes a human physician who notices that the patient has a gunshot wound.  A surgery team swoops in and removes the bullet and patches the patient up.

OK… time to switch metaphors.  Your business is going along, operating normally.  A customer comes in the door with a complaint.  The product he purchased is broken within a few minutes of getting it. 

  • Do you respond like a robot and give him a new product and a coupon for 10% his next order?
  • Does the physician ever arrive to take a look and decide that the company is manufacturing low quality products?  Is anything ever done about the underlying problem?

Enterprise architecture has the same problem in more ways than one.

  • If someone complains that the EA team is not providing value, do you respond like a robot and send your architects to jump onto a visible and important project and “be useful?”  Do you follow up to diagnose the root cause of the perception?  Do you deal with issues in governance, communication, information accuracy, process integration, and expertise?
  • If you notice a complex area of the business is never actually getting cleaned up, and that complexity is causing business agility problems, do you create an initiative to simplify the complexity and then stop there, or do you follow up with a project to address the institutional decision making, roles and responsibilities, and design principles that led to complexity in the first place?

A word of advice: when a problem erupts: triage is important, but surgery may be necessary.   Don’t solve the underlying problem without dealing with the symptoms.  Don’t deal with the symptoms without also addressing the underlying problem.