/Tag: Business Architecture

EA Debt

By |2014-06-24T23:41:00+00:00June 24th, 2014|Enterprise Architecture|

(Note: I’ve added an addendum to this post)

It has been many years that we have lived with the concept of technical debt.  Martin Fowler did a good job of describing the concept in a 2003 article on his wiki.  Basically, the idea is that you can make a quick-and-dirty change to software.  You will have to spend time to fix that software later.  That additional time is like an interest payment on debt that you incur when you made the change.  Fixing the code to make it more elegant and clean “pays down the debt” so that future changes cost less to make.

I’d like my fellow practitioners to consider joining me in extending this idea to the enterprise.

Organizations change, and sometimes the changes have to be made quickly.  Processes that are implemented “quick and dirty” may have poorly defined roles, overlapping responsibilities, and duplicate accountabilities.  It may work, and it may be necessary to hit a deadline.  However, these “dirty” processes have the same problem that dirty code does – it costs more later to fix them. 

In a sense, partial process or accountability “fixes” in an organization create “enterprise architecture debt” or “EA debt.”  We run into it all the time in organizations.  Here are some examples that I’ve personally seen:

  • One team is responsible for checking the quality of all manufactured products and making sure that they get to distributors.  However, products that are custom developed have their own quality check and distribution function.  Effectively, two different teams duplicate a couple of functions.  This could be simplified, and doing so would likely reduce costs and improve consistency in quality checks. 
     
  • The marketing team uses data mining techniques to identify potential customers (prospects) and enters them into a system along with attributes like segment, predicted value, and targeting within specific marketing programs.  When a new customer reaches out to actually purchase a product, however, the customer record is created in a CRM system that is not linked to the marketing record.  Consistently linked customer information could provide valuable information about the effectiveness of marketing programs as well as enriching customer information for the sale of service and ongoing sales.
      
  • An outpatient specialty radiology department in a Hospital requires patients to be registered separately from other hospital services in order for patients to be handled.  For most patients, this is not a problem.  However, for patients within the hospital, the separate registration requirement creates opportunities for errors as information is hand-transcribed from one system to another.
     
  • A retailer sets up an e-commerce division to sell their wares online.  However, inventory and warehousing the new e-commerce site is not integrated into existing store systems.  The ecommerce “store” is treated as another physical store.  This works, but any attempt to allow customers to purchase online and pick up at a store become problematic because the retailer has no way to handle purchases made in one store to be fulfilled by another.
     

These, and a thousand more situations, are the result of “partial” or “messy” implementation of organizational changes.  They are a form of “EA debt” because any change to the organization that hits these capabilities will be more expensive to change in the future as complexity slows down the organization.  In effect, EA debt is like taking a Lego set and gluing the pieces together.  The parts will remain just as they are, but the will be very difficult to change in the future if something needs to change.  (Apologies to “The Lego Movie” for the metaphor).

Why call this “EA debt?”  Because it is not a financial term.  It is nearly impossible to accurately measure all of the EA debt in an organization.  It is, however, fairly straight forward to measure monetary debt.  So we have to be careful not to use terms like “enterprise debt” or “organizational debt” as these may be confused with general accounting concepts.  Just as technology teams sometimes twist the concept of an “asset” to apply to an information system, Enterprise architects are using the metaphor of debt to refer to one of the root causes of difficulty in making organizational change.

Addendum: I guess I shouldn’t be surprised that this idea is not novel.  It’s fairly self-evident.  It was my mistake that I didn’t go looking for other references to the idea before writing the above post.  Laziness.  No excuse.  While the concept of technical debt does in fact trace back to Ward Cunningham (inventor of the Wiki), as discussed by Martin Fowler in the referenced blog post, the application of that concept was first applied to EA in 2008 in the Pragmatic EA Framework, and is part of the current version as well.  I’d give a link to that presentation if I could but the best I’m able to do at this time is a general link to PEAF at http://www.pragmaticea.com.  Kevin directly responded below with links into his material .  It is no disgrace to be in the shadow of Kevin Smith (author of PEAF).  It is an error, however, to appear to originate the idea.  For that, my apologies.

Climbing the ladder from EITA to EA

By |2014-03-10T13:50:59+00:00March 10th, 2014|Enterprise Architecture|

One of the most common problems in Enterprise Architecture, and one I get asked about routinely, is the “ladder” problem.  Many Enterprise Architecture teams are formed by assembling a group of talented technologists into a team and giving them a charter to “go do EA.”  The problem is that most of these teams have no credibility outside the technology group, and cannot really operate as a “bridge between business and IT” if they don’t have the relationships and knowledge that they need to be an Enterprise Architect.  Building those relationships and that credibility takes time… sometimes many years.  Until they make that transition, the team is an Enterprise IT Architecture team (EITA) and while that is useful, the value proposition of EA remains unfulfilled.

I call this “climbing the ladder” from EITA to EA. 

While the entire team should work on this, only a few will succeed.  Good news: That’s all you need.  However, it’s important that everyone makes the attempt to climb the ladder.  As a manager, I have no magic “test” to determine, for certain, which member of the team will make the transition and which won’t.  I once thought I did, but reality proved me wrong.  So everyone makes the attempt.  Those who remain EITA’s can continue in that role for the EA team, or they can transfer to a different group where their technical skills are valuable and needed.

So, how is this done?  How does an individual EITA climb the ladder?

You need four things:

  1. business knowledge
  2. empathy (and good reflective communication skills)
  3. courage
  4. air cover

Business Knowledge

Business knowledge is the one that should, on the surface, be the easiest of the three to acquire.  Unfortunately, it seems to be one that is sorely lacking among EITA’s who are attempting to make this transition.  What do I mean by business knowledge?  I mean the ability to understand the basic concepts of business at a working level.  In other words, can you answer these questions coherently:

  1. Explain the difference between value and cost from the perspective of the provider of a product or service
  2. For Contoso in Q4 CY2013, they saw sales to new customers increase while market share decreased.  Explain.
  3. Give an example of a disruption in bricks-and-mortar business triggered by mobile computing
  4. When your company acquires another company for cash, explain how the balance sheet is impacted
  5. Explain how opening a new channel for your customers can result in a decrease in sales
  6. Give an example of a good strategy that failed in your industry or market.  Why did it happen?

Where do you get business knowledge?  There are a gazillion books that will give you the basics.  Universities are helpful as well.  With the wide array of support, Enterprise IT Architects should have no difficulty learning these things… yet it’s startling how many don’t.  I have some friends who insist that an MBA is needed.  I disagree with that, but college courses do help.  I hold out the most hope for success with a blended program like that offered by the Enterprise Architecture degree at Pennsylvania State University. 

Empathy and Communication Skills

There has been a good bit of ink spilled about technical topics: mobile platforms, SOA, security, etc.  These help with the EITA side of the job.  But they don’t do much for the architect who needs to climb the ladder.  To successfully make that move, most architects need to invest in training on their soft skills.  This means building up the following:

  • Listening – Can you elicit the emotional context behind your stakeholders strategies and goals?  Can you truly “hear” them?  There are courses, and books, and online videos, that can help you to become a more conscious listener.  Not only will this help you climb the ladder, it will also help you in your relationships with family and friends. 
     
  • Empathy – The art of empathy in business is one where you feel as your stakeholder feels.  Don’t confuse with sympathy.  Big difference.  Empathy is a selfless act, and your ego has to be put into check if you are going to learn empathy.  There are many folks in architecture who struggle with ego, ambition, and condescension.  I struggle as well.  But if you don’t tame this beast, and build your capacity for empathy, your stakeholders will have a difficult time connecting with you.  As the old saying goes: They won’t care what you know, unless they know that you care. 
     
  • Negotiation – You will be frequently called upon to find a way for two people, with different perspectives, to come to a solution where both people “win”.  These “win-win” solutions form the basis for successful endeavors of many kinds, not just in business.  But if you don’t know how to negotiate, your usefulness as a bridge-builder is seriously limited. 
     
  • Positional Awareness – this means the ability to “see” how the organization works from various perspectives, and to position yourself, and your value proposition as to provide you the ability to influence that system.  It also means being aware when other folks are doing the same thing, which has the effect of changing your landscape out from under you.  Some folks call this “politics.”  I call it necessary.
     
  • Selling – Yep, I said the dreaded “s” word.  Many architects view “sales” as a dirty word.  After all, Sales people use emotions, leverage relationships, and often don’t even understand the details of what they are selling.  The sale is more important than the actual people!  Ouch.  It’s true.  Sales professionals are often competitive individuals who have been known to compromise their integrity for the sake of the transaction.  But that doesn’t mean that the tools and techniques of sales aren’t useful, or effective, or critical to success.  These techniques are mission critical.  So take professional training in sales.  How to hook a lead.  How to build excitement.  How to connect to your stakeholders’ underlying motivations.  How to use emotion to communicate.  How to ask for the sale.  How to follow up.   The use of color, design, and simplicity to convey a message.  All of that. 

Courage

Did you know that courage can be learned?  I guess I always knew it was possible, but I never really considered it until I found myself with a situation where I needed to use courage, and needed others to do the same.  I was playing the role of a SOA architect, and I needed to convince development teams and technical architects to adopt a set of patterns that would help the enterprise, but may actually add complexity to their own project.  I needed to walk into rooms and see if I could demonstrate, convince, cajole, argue, and/or negotiate my way to changes that were not in the obvious best interests of the team itself. 

I taught myself courage.  I taught others courage as well.  Part of teaching, and learning to be courageous, is to put your efforts into perspective.  See your work as necessary to a “bigger picture” and be very aware of how much you can get away with before others decide that they cannot actually follow your lead or support your efforts.

Courage is not the lack of fear or operating outside of dangerous situations.  It is the conscious choice to move ahead despite danger.  As the Will Smith character in “After Earth” tries to teach his son, “D
anger is real.  Fear is a choice.”  Sometimes, as an Enterprise Architect, you will have to tell someone powerful something that they don’t want to hear.  The situation can end badly, impacting your ability to continue working as an Enterprise Architect, or worse, resulting in you losing your job.  These dangers are very real to many EAs. 

Courage means that you will need to move ahead anyway.  It does not mean you should be reckless in the face of danger.  It is OK to be cautious at times.  But real success often requires boldness, and your bold actions cannot be made without the courage of your convictions.      

Air cover

There is a difference between “being courageous” and “being stupid.”  The difference is support: do you have the support you need, by someone higher up the food chain, to take on the challenge of climbing the ladder in most organizations.  This support from above is critical to your success.  I call it “air cover” (a reference to a military situation where ground troops can request a deadly strike on an enemy to be dropped from planes, missiles, or artillery). 

In a business setting, air cover means that you have successfully convinced leaders in various places around the company that you can be trusted.  They believe that you are valuable and that your motivations are in the right place.  So when a problem occurs, or one of your standards is challenged, or your roadmap makes a stakeholder angry, that leader can step in and sooth sore egos. 

I cannot indicate the importance of air cover.  For architecture managers, if you don’t provide air cover for your team, you are worse than an ineffective leader… you are a disgrace.  And for architecture practitioners, if you don’t build the relationships you need to build so that you will have the air cover when you need it, you are not being courageous.  You’re being stupid, reckless, or chaotic (take your pick).  To climb the ladder, someone has to be holding the ladder.  That’s your air cover. 

Conclusion

Climbing the ladder is a difficult challenge for any Enterprise IT Architect (EITA).  It takes dedication, support, and some significant innate abilities.  However, for many who take on this challenge, the rewards are excellent.  I truly love Enterprise Strategy Architecture.  I hope to see many of you “in the trenches” with me, fighting to make our ecosystems healthier, stronger, and more agile every day. 

Caveat: certification and frameworks

You’ll notice that I never mentioned Certifications or Frameworks in the discussion above.  That’s because I’ve met and known hundreds of Enterprise Architects.  Certification was only useful to make them more effective as an EITA.  It made no difference for climbing the ladder.  Certification will help with some skills and a great deal of knowledge.   A certification may build confidence, reduce churn in your team, and make your results easier for others to read and follow.  I’m not putting down certifications.  I’m just pointing out that this step comes with experience, not certification.  At least, not yet.

Technorati Tags:

Diversity Versus Replication of Organizational Processes and Information

By |2013-10-23T16:35:00+00:00October 23rd, 2013|Enterprise Architecture|

I recently had the pleasure of joining a discussion among organizational development professionals.  During that discussion, one individual asked an interesting question: in a distributed organization with multiple operating units, spread geographically around the world, should the organizational structure of each unit be similar?

The illustration that the questioner used: organization structure (org charts).  Should the org charts look alike?

As examples, he mentioned two business units of his own company, one that was fairly “steep” with a Managing director having two direct reports, both Vice Presidents, and each of them having a small number of VPs under them.  The alternative was a different unit of the same company where the Managing director had something like 16 functional managers reporting directly to him or her.

Unit one looked something like this:

image 

Unit two looked something like this:

image

The questioner illustrated his example by pointing out in the “steep” structure (unit one), the director of Human Resources was somewhere down at level four.  In the “shallow” structure (unit two), the director of Human Resources reports directly to the managing director. 

So here’s the problem he faced: the company had a hard time moving a qualified director of Human Resources from unit two to unit one, because he would be “dropping” to four levels below the managing director, and that meant less control, less access, and less effectiveness.  On the other hand, the executive in unit two, who had a large number of direct reports, frequently complained about being overworked.

Should we force each of the units to have the same hierarchy? 

Think about it.  The company had many structures, and they were different from one another, making it difficult for a person doing work in one of those structures to translate their work, their processes, and their efforts from one to another.  This limited mobility of workers and cross-pollination of skills.  It limited information integration and consistency.  It limited process reuse.  It meant that quality of the output could be quite variable, even though each of these different units produce the same (highly complex) product!

image

 

Before I go on… what do you think?  Should the company have the same structure in every one of their geographically diverse operations? 

Would you change you mind if I told you that some of those business units were two orders of magnitude larger and more profitable than others?

Which is better: diversity or consistency (replication)?

The first observation I’d like to make about this “problem” is that it is a problem by choice, and not by accident.  The organization is NOT a franchise model.  This is a large organization that has grown over the past 100 years to be a very successful company.  Most of the life of the company preceded the information technology revolution… before computers and teleconferencing and instant communication.  Each of the business units had no choice but to operate independently.  Corporate management, early on, chose to allow each of the business units to structure itself as needed based on local conditions, people, culture, regulations, and resources.  In the terms of Jeanne Ross (author of “Enterprise Architecture As Strategy”), the organization was not a replication model.  It was a diversification model.

That said, each of these business units provided essentially the same product in each of a half-dozen different locations around the world. 

Only someone who had read Jeanne’s book would recognize that the underlying question in the room was simple.  The person posing the question saw a great many advantages to having a “replication operating model,” and didn’t see an advantage to having a “diversification operating model.”  He was seeking input on whether he was the only person who could see the advantage to making a switch.  (of course, he was not the CEO, so it was a fictional exercise, but a useful one nonetheless).

Switching from a Diversification Model to a Replication Model

There are many problems with making a switch from a diversification model to a replication model.

  1. It is fairly complex to do.  An “ideal” model must be created for all of the business units to follow.  Since none of the current business units is likely to have that “ideal” model implemented, you’d first have to create an “ideal” model and then implement it in one place to get feedback on how it actually works (if it does).  That takes time.  Once you’ve made changes in one place, rolling it out means moving people, recreating processes, and restructuring information and accountability across each of those units.  It’s essentially the same a tearing down a company and starting over.  Only each of those business units will have to keep operating while it is going on, and will have to show profit at the end of the year. 
     
  2. Loss of business unit innovation.  Companies making that kind of switch usually screw up at the “ideal model” stage because creating the “ideal” model rarely involves the right conversations with every one of the business units involved.  As a result, innovations that are working well in one area can be lost because those innovations were not copied to the “ideal” model, even if they would have been useful to everyone.  Importantly, innovations that were about to be implemented in any one unit, but had not been, are completely discarded.  Evolution of the business units themselves can be thrown backward by years.  Also, by the very fact that there is now “replication by policy,” it becomes very difficult for any further innovation to occur because it has to occur once and then be replicated everyone else, regardless of whether that innovation has the same ROI in each business unit.  (Hint: it nearly never does).
     
  3. Loss of local adaptations.  There is a notion that “the person closest to the work knows best how to do it.”  In the case illustrated above, the two business units being compared were in different parts of the world, with different business cultures and business expectations.  The PEOPLE in these organizations have a specific idea of the way that business operates.  They have relationships, cultural expectations, and accountabilities neatly arranged to suit those local conditions.  Your “ideal” structure will come from you, and you live in a business culture.  We all do.  Therefore, you have assumptions about what will and will not work.  If you impose your structure on a group of people, be prepared to re-educate every single person in every single business unit on the “one right way” to do business… and then you’d better hope that the “ideal” you have created will be more effective in a local environment than the one that was previously there.  (Hint: it probably won’t be).
     

A better way

As I have explained in my previous discussions of “Minimum Sufficient Business Integration,” I believe that many modern organizations can benefit from taking the time to find the minimum set of capabilities needed across business units to meet key corporate goals.  After that minimum set is understood, the rest of the choices can (and probably should) be left up to the people closest to their customers and suppliers.  At best, a “reference model” can be widely shared that represents your idea of what an “ideal” structure would look like… but without enforcement from above.

Of course, it can take a little thought to understand what is the “minimum” level of commonality that should be imposed.  It should be very carefully considered because, and this is important, for there to be value in this concept, that level of commonality will be strictly imposed.  No exceptions.  On the other hand, every little thing included in that “common set” will be VERY expensive to roll out consistently across a wide array of business units, so the absolute minimum set should be included.

Conclusion

My recommendation for this situation is to remain in a diversification model, but to consider moving a little closer to process and information consistency through minimum sufficient business integration (MSBI).  This means having consistency for those areas that absolutely positively must have consistency, and then to allow diversity (and innovation) to grow atop that minimum set.

In that case, the org charts would probably remain different from one another… and rightly so.

Happy architecting!

P.S.: I also want to point out that the notion of minimum sufficient integration takes place at the level of business capabilities.  Not business processes.  Not information elements.  Not business functions.  Capabilities.  So if your business architecture methods don’t use capabilities (or if you don’t know what capabilities are), you cannot use this methodology.  This post is not going to teach you what a business capability is, but I’ve blogged about them dozens of times, as have hundreds of other folks including the Business Architecture Guild and the Business Architecture Society.  Start there.

The Purpose of an Enterprise Architecture Framework

By |2013-10-14T23:15:00+00:00October 14th, 2013|Enterprise Architecture|

Can Social Media create new ideas?  Here’s an example where the answer is “yes.” 

I recently blogged about EA models, and what makes them interesting.  I was thinking about providing insight to people who were in the mood to send me updates to the EBMM… a rather tactical post to deal with a rather pedantic an uninspiring issue: logistics of change.  On Twitter, however, a discussion broke out among rather distinguished architects that took the logic of my post to it’s natural resolution, and it was well beyond my limited thinking to have considered it when I wrote the original blog post.  In other words, they read my post, added insight, and create a novel idea, derived from mine, that I had not considered.

It started with consummate twitter user Mark Nielsen (manielse) noticed my blog post and recommended it.  Tom Graves retweeted Mark’s comment and added his own.

@tetradian: MT @manielse: By @nickmalik: What makes models interesting <<blog link>> #EntArch >important for all EAs

Richard Veryard then added his own interpretation, restating the premise of my last post.

@richardveryard: #entarch @tetradian @manielse  @nickmalik implies purpose of model is to answer specific set of questions – support a given reasoning process

Tom then did something really interesting.  Using a little judicious editing, he create a new conclusion: one that I did not make in my post.

@tetradian: @richardveryard “implies purpose of model is to … support a given reasoning process” – yes, agreed / @manielse @nickmalik #entarch

And there we go into new territory.  Richard caught an implication from my reasoning that I had simply assumed, without examining or testing.  Tom then took that implication and used it to reach a higher implication, and called it out in the open.  So let’s examine that resulting implication and then apply that logic a bit further to see where it goes.

The purpose of a model is support a given reasoning process

My prior blog post focuses on the questions that you want your model to answer.  You create a model to answer a question.  If you don’t know what the question is, you won’t answer it (or you will bury your answer in details that are not pertinent to the question).  So first ask the question. 

But why are we asking a question?  This is the leap that Richard and Tom took.  Let’s understand that asking questions, for their own sake, is a rather detached activity.  Enterprise Architects tend to live a little closer to the practical world than that, so we are asking questions that are useful, not just interesting.  And what makes a question useful?

We ask a question, and model the answer, for a couple of reasons:

  • We want to guide thought in ourselves.
  • We want to guide thought in others.
  • We want to answer a question asked of us.
  • We want to examine the results of asking a question that we find particularly interesting.

 

Note that I did not say that we are guiding action.  We are guiding thought.  In some cases, thought precedes action.  In other cases, not so much.  But the role of the Enterprise Architect may be to suggest action, and it may include overseeing that action to ensure alignment to goals, but Enterprise Architects are rarely the driver of action.  Someone else funds the action and drives for conclusion.  We are the people who guide thought.  If we were living in a feudal society, we are not the King… we are his advisors. 

The idea of “supporting a reasoning process” is clearly the first two bullets.  We want to guide thought.  We are walking through a reasoning process, either for our own decisions or for the decisions we will lead others to (sometimes both at once). 

Tom’s edit takes on new ground because he allows us to draw a meta-conclusion: that ultimately a model may lead us to a reasoning process when we were not actually planning for it to.  This is the fourth bullet above, and one that I wasn’t really considering when I wrote the post.  What if we don’t know where the model will lead, until we create the model?  What if we are simply modeling because doing so is literally a form of reasoning in itself?  What if we can ask questions of the model that we didn’t think were relevant and wouldn’t have bothered asking, but can only ask because we have the model to answer it?

Now, to extend the thinking just a bit.  What is an architectural framework?  While there are many definitions, there is one possible definition I’d like to propose: an architectural framework is composed of a reference model describing the essential elements of a system, and a series of methods for building instance models within that reference model.  In other words, a framework is a model and the tools to use it to build more models.

The Purpose of a Framework

If the purpose of a model is to support a reasoning process, then, by extension, the purpose of a framework is ultimately to support a particular theory of organizational evolution. 

This notion flies in the face of most framework development efforts. 

Taxonomic transformation, like that proposed by Zachman fans, is a model-driven design approach to mostly IT solutions.  The descendants of TAFIM, including TOGAF and DODAF, follow a methodological approach that builds from a solution standpoint, but which supports the core concept of a single-page enterprise architecture.  Service oriented frameworks like MODAF, FEAF and NGOSS are somewhat middle out, with the core concept being composability of services.  Business oriented frameworks tend to focus on classification of motivations, and usually start with some kind of metamodel like the OMG BMM, the BMGen canvas, or my own EBMM.

Under here are the theories of evolution of a successful organization… but it will take a little archeology to figure out what those theories really are.  Just as we can look at the remnants of cultures long passed and deduce elements about the way that those people lived, we can look at frameworks and deduce the ideas that the framers of the framework had about how organizations could, or should, or must develop. 

Frameworks, like models, are designed to answer a specific set of questions.  But more than that, they are designed to support a logical train of thought from understanding of a situation through proposing a pathway through it to meet a vision of success.  If your organization can only really support one fundamental approach, then you must choose the frameworks that can deliver on that approach in an effective way.

Consider these aspects of each framework.   Consider the idea that frameworks are an outward expression of inner assumptions.  Then, go looking for those assumptions.

If this is where we start, with the underlying assumptions, it is fairly easy to see why some frameworks are appealing to specific people and even corporate cultures, where others are not.  If the framework doesn’t support your view of organizational transformation and evolution, it is tougher to understand and apply it.  Your organization’s culture, politics, and history may end up doing more to help you to select an EA framework than you think.  After all, you can always extend a framework to include a method, but it is tough to deal with the problem of a framework that simply doesn’t support the way people in an organization think about themselves and their mission.

This is important because EA has been struggling for years to understand what the possible directions are for academic study and scientific examination.  Using this approach, we can refine and develop succinct theories of organizational development, merge similar frameworks, build commonalities among approaches, and even compare results of company development “in the wild” to see where these approaches lead.

And the Credit goes to…

Who authored the new idea?  Who cares.  I won’t take all the credit.  Perhaps it was first Richard Veryard riffing on my post and then Tom Graves creating a new idea by removing words. Perhaps I went to the conclusion after reading that edit.  I don’t know.   Perhaps it was just social.  Perhaps it is an idea that has already been proposed elsewhere.  I respect that possibility as well. 

Regardless, I think there is a real idea under here.  We have artifacts, real artifacts, to take to our original authors as well as social anthropologists and archeologists.  Let’s ask for analysis and intent.  Let’s find out what those underlying assumptions really are.  We may discover that there are underlying theories of organizational evolution upon which we can base the ongoing development of the EA profession.

Ten Ways to Kill An Enterprise Architecture Practice

By |2013-09-05T18:30:19+00:00September 5th, 2013|Enterprise Architecture|

Have you seen practices that you know could kill an Enterprise Architecture practice?  I have.  A recent LinkedIn thread asked for examples, and I came up with my top ten.  I’d love to hear your additions to the list.

How to screw up an EA practice

  1. Get a senior leader to ask for EA without any idea of what he is going to get for it. If necessary, lie. Tell leaders that EA will improve their agility or reduce complexity without telling them that THEY and THEIR BUSINESS will have to change.
  2. Set no goals. Allow individual architects to find their own architecture opportunities and to do them any way they want.   Encourage cowboy architecture.
  3. Buy a tool first. Tell everyone that they need to wait for results until the tool is implemented and all the integration is complete.
  4. Get everyone trained on a "shell framework" like Zachman. Then tell your stakeholders that using the framework will provide immediate benefits.
  5. Work with stakeholders to make sure that your EA’s are involved in their processes without any clear idea of what the EA is supposed to do there. Just toss ’em in and let them float.
  6. Delete all the data from your tool. Give no one any reason why. You were just having a bad hair day.
  7. Get in front of the most senior people you can, and when you get there, tell them how badly they do strategic planning.
  8. Change your offerings every four months. Each time, only share the new set of architectural services with about 20% of your stakeholders.
  9. Create a conceptual model of the enterprise that uses terms that no one in the enterprise uses. Refer to well known business thinkers as sources. When people complain, tell them that they are wrong. Never allow aliases.
  10. Every time you touch an IT project, slow it down. Occasionally throw a fit and stop an IT project just for fun. Escalate as high as you can every time. Win your battles at all costs.

Your career will be short. 🙂

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

By |2013-07-06T15:12:08+00:00July 6th, 2013|Enterprise Architecture|

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.

The “Right” Representation of the EA Value Cycle

By |2013-04-29T17:10:58+00:00April 29th, 2013|Enterprise Architecture|

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 compa
ny 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?

Humility and the Art of Enterprise Architecture

By |2013-02-26T16:46:41+00:00February 26th, 2013|Enterprise Architecture|

As a lot, Enterprise Architects are not terribly humble people.  We name frameworks after ourselves, and sometimes go to great lengths to correct the “misinterpretations” of others who describe our work in a way that we don’t agree with. 

Yet, recognizing that the field is young requires that we should be willing to change as the field of EA changes; that we should be willing to look back on our models, developed in the past, and admit that we missed a few steps that we wouldn’t miss today.

I recently had the opportunity to discuss, on LinkedIn, a blog post that I made five years ago.  I look back on that blog post and must admit that my opinions are a bit different now than they were five years ago.  I still agree with my post, but I would certainly use different words today than I used in the past.  I am more than willing to admit it. 

I also look at the efforts of Alexander Osterwalder whose Business Model Canvas has proved both practical and flawed.  He missed the fact that he needed to create a differentiation between the customer’s needs and the value proposition of the business offering to fill some of those needs.  Did he go back and create an updated canvas?  Nope.  He created a new canvas to describe demand as though it fits with his older one (hint: it’s a mess). 

The venerable John Zachman, probably one of the most humble men I’ve met, also made this same mistake.  While his original model was only a couple of columns, and was updated only a few years later into the table we see today, the field of EA has changed.  The table is no longer representative of companies with multiple business models (most of them) and the lack of a “customer” row simply relegates his "ontological table” to the dust bin. 

Neither man will change.  They have “legacy” models, with their names attached.  To paraphrase Forrest Gump, humble is as humble does.

I would like to think that my willingness to upend my EBMM and replace it periodically with new versions shows my willingness to admit that (a) I’m often wrong, and (b) I’d rather learn than become stale.  That said, I’m no paradigm of humility, myself. 

After all, a truly humble EA would not have written this blog post. 

(As my teenage daughter would say: Oh snap, you pwned yourself!)

Should Business Architects use the Business Model Canvas at the Program level?

By |2013-01-31T10:51:21+00:00January 31st, 2013|Enterprise Architecture|

In the Open Group conference at Newport Beach, I listened to a series of presentations on business architecture.  In one of them, the presenter described his practice of using Osterwalder’s Business Model Canvas to create a model of his program’s environment after a business program (aka business initiative) is started.  He felt that the canvas is useful for creating a clear picture of the business impacts on a program.  There are problems with this method, which I’d like to share in this post. 

Let me lay out the context for the sake of this post since there is no business architecture “standard vocabulary.” 

A “business program” is chartered by an “enterprise” to improve a series of “capabilities” in order to achieve a specific and measurable business “goal.”  This business program has a management structure and is ultimately provided funding for a series of “projects.”  The business architect involved in this program creates a “roadmap” of the projects and to rationalizes the capability improvements across those projects and between his program and other programs. 

For folks who follow my discussions in the Enterprise Business Motivation Model, I use the term “initiative” in that model.  I’m using the term “program” for this post because the Open Group presenter used the word “program.”  Note that the presentation was made at an Open Group conference but it does NOT represent the opinion or position of the Open Group and is not part of the TOGAF or other deliverables of the Open Group.

The practice presented by this talk is troubling to me.  As described, the practice that this presenter provided goes like this: Within the context of the program, the business architect would pull up a blank copy of the business model canvas and sit with his or her executive sponsor or steering committee to fill it out.  By doing so, he or she would understand “the” business model that impacts the program. 

During the Q&A period I asked about a scenario that I would expect to be quite commonplace: what if the initiative serves and supports multiple business models?  The presenter said, in effect, “we only create one canvas.”  My jaw dropped.

A screwdriver makes a lousy hammer but it can sometimes work.  The wrong tool for the job doesn’t always fail, but it will fail often enough to indicate, to the wise, that a better tool should be found.

The Osterwalder’s business model canvas makes a very poor tool for capturing business forces from the perspective of a program.  First off, programs are transitory, while business models are not.  The notion of a business model is a mechanism for capturing how a LINE OF BUSINESS makes money independent of other concerns and other lines of business.  Long before there is a program, and long after the program is over, there are business models, and the canvas is a reasonable mechanism for capturing one such model at a time.  It is completely inappropriate for capturing two different models on a single canvas.  Every example of a business model, as described both in Osterwalder’s book and on his web site, specifically describe a single business model within an enterprise.

I have no problem with using business models (although my canvas is different from Osterwalder’s).  That said,  I recommend a different practice: If the business initiative is doing work that will impact MULTIPLE business models, it is imperative that ALL of those business models are captured in their own canvas.  The session speaker specifically rejected this idea.  I don’t think he is a bad person.  I think he has been hammering nails with a screwdriver.  (He was young).

Here’s where he made his mistake:

multistream value chain

In the oversimplified value stream model above, Contoso airlines has three business models.  The business owners for these three businesses are on the left: Bradley, Janet, and Franklin.  Each are primarily concerned with their own business flows.  In this oversimplified situation, there are only two programs, each with one project.  If the session speaker were working on the Plantheon program, his idea works.  there is only one business model to create.  That nail can be hammered in with a screwdriver.  Lucky speaker.  Showing Franklin his own business model is a good thing.

But if we are working on the Flitrack program, what do we show Franklin?  if we create a “generic” canvas that includes cargo, he will not recognize the model as being applicable to his concerns.  He will not benefit and neither will the program.  In fact, Franklin will think us fools because he had a presentation from Plantheon yesterday showing him an accurate model… don’t you people talk?

Program Flitrack should have one-on-one conversations with Bradley and Janet to develop their business models.  The business model that Franklin cares about does not need to be created again.  It can come out of the repository.  The Flitrack program would consider all three models as independent inputs to the business architecture of the organization impacting the program. 

Anything less is business analysis, not business architecture.

Steps To Create a Core Diagram

By |2012-12-19T08:34:41+00:00December 19th, 2012|Enterprise Architecture|

To be fair, these are steps to create a solid understanding of the architecture of a business, but the deliverable is a core diagram, so that’s the title of the post.  I first wrote about a method for creating core diagrams about a year ago, as I was preparing for a talk on the subject at the Open Group conference in San Francisco.  Now that I’m preparing for another Open Group conference, I find myself filling out some of the details from the previous effort.  Most of the text below is copied from an e-mail that I sent to a fellow business architect who was asking about how to create a core diagram.

The text below describes a five step process

  1. Collect a list of your organization’s business models
  2. Create or leverage a taxonomy of capabilities that reflect differentiation in business processes
  3. Differentiate each capability on the basis of Ross’ operating model taxonomy (level of Information Integration and level of Process standardization)
  4. Make an educated guess about the operating model of the company
  5. Draw the core diagram and build understanding around it

 

Understanding how to create a core diagram starts by collecting a list of the business models that your organization performs. Each business model is unique and different from the other ones. Each will require different capabilities and will often drive variations in those capabilities for the sake of market or product differentiation. You cannot create a core diagram effectively without the list of business models.

So what is in a business model? I’ve blogged about that fairly well. A business model is a composition of elements that describes how and why a value proposition exists, who it is for, and what it drives in terms of internal and external requirements. The diagram is below. (click to enlarge)

Metamodel for a Business Model

Once you have the initial list of business models, you will want to engage with direct business stakeholders. Make sure that they understand the concept of a business model, and what makes a business model unique from other business models (e.g. selling the same product in the same way to the same people in another country is NOT a unique business model, but selling a product in three different ways to three different, potentially overlapping market segments within one country probably represents three business models). Engage. Build relationships. This is your first shot.

Once you have that list fairly well baked, you have step two on your hands: a capability taxonomy that reflects process differentiation. In this case, it is a good idea to start with a high level process taxonomy like the ones made available for free from the APQC. I don’t know if there is one for financial services yet, but there should be. If not, you can start with a general one, but it will take some editing. You want your capability taxonomy to be worded in such a way that it represents “things that could be done” without reflecting the way in which they are done. For example, “customer identity management” is OK, but “customer deduplication” is not, because we want to make sure that customers have an appropriate identity but the organization may not want to remove duplication in order to do that.

This requires some editing of a large list of items in a hierarchy. Excel is OK for this. There may be other tools as well… I haven’t experimented past Excel. This is the second point where it is good to be engaging with business stakeholders. Get their help to describe their business model to you in terms of capabilities, and make sure that all of their capabilities are included in your taxonomy somewhere (usually around the third level down in the tree).

Step three is to differentiate each business capability on the dimensions suggested in the EA As Strategy book. (This can be done at a high level. If your taxonomy has more than 200 business capabilities in it, don’t use the most detailed level(s) of the taxonomy. No one has patience for the details in a core diagram.

Draw out a grid like the one illustrated in the EA As Strategy book, only make it empty.

Diagram illustrating the dimensions of Operating Models with Integration (low and high) on the Y axis, and Standardization (low and high) on the X axis

In each one of the boxes, write in the capabilities that are well understood by a particular business stakeholder, then go to that stakeholder and validate your choices. Make sure that you have placed the correctly for that stakeholder’s particular business models. Note that very few stakeholders will have a valid opinion about capabilities that are NOT part of their particular business model, so don’t show capabilities that they don’t care about.

You will quickly discover that most folks agree on some things and disagree on some things. Where a single capability shows up in multiple businesses, one stakeholder may say that it needs high standardization, while another will say that the capability needs low standardization (== high flexibility). Take note of these disagreements. THEY ARE THE VALUE POINTS FOR BUSINESS ARCHITECTURE.

On everything you can get reasonable agreement on, go ahead and create a master table that has the capabilities differentiated in the manner above. That will probably be about 90-95% of your business capabilities in your taxonomy.

Step four is to make an “educated guess” about the operating model that your organization has. It’s a guess because most organizations are difficult to read and no one person will be able to answer your question about what the company as a whole looks like. Most of the time, you can start with the generalizatio
ns that Jeannie Ross made when describing the four operating models in her book “Enterprise Architecture As Strategy.” If there are a large number of capabilities in the “High Integration, High Standardization” box, you can suggest that your organization is a “Centralization” model. If, on the other hand, there are a large number in the “High Integration, Low Standardization” box, you can suggest that the organization is a Coordination model. This is the educated guess part because there is no good formula for making the guess. By this point, you will know a great deal about the organization so your guess is as good as your stakeholders.

Step five is to take a cut at your core diagram… Draw it out and then work with your stakeholders to get common understanding.

For each of the four styles of models, there are different styles of core diagrams. The centralization model tends to break out capabilities by functional area since there is very little (intentional) duplication. So it will be a diagram with a series of functional areas as boxes with the capabilities for each function listed in the boxes. Good idea to put the name of the person accountable for that business function in the title of the box. Lines between the boxes represent flows of information or value between them.

The Replication model is somewhat similar. There will be some functions that are owned by “corporate” while the rest are replicated into EACH of the operating units, so there will be two large “areas” on your diagram. The corporate area will have some functions with capabilities in them, and a single “replicated” area will have the remaining functions with capabilities in them. This is wildly valuable to business planners because they can get agreement among the leaders of each replicated unit about what each one of the is accountable to do and what they MUST depend on the corporate unit to do.

The collaboration model tends to be “hub and spoke” with the hub being the most integrated capabilities and the spokes being unique to each of the business models (or in some cases, small groups of business models that share a lot of capabilities). The lines tend to be information flow, not value flow. The capabilities in the spokes are usually duplicated between the different business units but they (should be) the capabilities that each business unit needs in order to differentiate itself or its products in the marketplace.

The diversification model is the most complex because the “corporate” unit tends to have a small number of core capabilities (often just financial ones) with each of the subsidiaries having a nearly complete and quite independent set of functions with massive duplication of capabilities across them.

I hope this gives you a good start in creating your core diagram.