When feasibility of integration is a measure of capability…

By |2010-01-29T07:08:44+00:00January 29th, 2010|Enterprise Architecture|

One of the jobs of an enterprise architect is to evaluate the business capabilities of an area of the business and determine if those capabilities are either strong, capable, or insufficient.  But what to do when two areas of the business overlap?

In some cases, as in mergers, or even consolidation of functions, you will find that two areas of the business have a need for a set of capabilities, and both have developed them independently.  This could be a good thing.  Lots of opportunity for independent movement.  On the other hand, silos in the business can be a problem for customer care among other things.  Silos also add complexity, in systems, data, and business process. 

So let’s say we have two parts of a business that have both developed the ability to manage inventory for the retail channels.  Two sets of warehouses.  Two sets of inventory management systems.  Two sets of supply chain relationships.  The warehouses are in the same geographical area.  So you bring together the inventories into a single building, but you still have two sets of systems. 

In this case, the capabilities associated with the processes, people, technology, and data may not be a simple comparison.  You may have strengths in both systems, and weaknesses in both, and yet it may be quite difficult to merge them.

In this case, the evaluation of business capabilities becomes more nuanced.  Instead of saying “contoso has strong capabilities in vendor management and shipment tracking,” you have to look ahead to the next step recommendations… which processes and systems will be used to manage the inventory of both businesses?  In that context, the ability of the existing systems to integrate, support multiple businesses, and adapt to change, becomes much more important than before.

Now, we are no longer comparing apples to oranges.  Now it is Fuji apples vs. Braeburn apples.  More measures are needed.

When Traceability is a “Bridge to Nowhere”

By |2010-01-23T13:57:18+00:00January 23rd, 2010|Enterprise Architecture|

One thing that many Enterprise Architects agree with: traceability matters.  If your job is to help the business to determine the strategic initiatives they should follow this year, the EA answer is to look to their goals and TRACE from their goals to their capabilities and, based on areas of weakness, TRACE to the initiatives that improve those capabilities.

The painful reality is that tracing from business goals may illuminate a decision that a business user is uncomfortable hearing.  For example, if a senior leader tells a general manager to “Solve Problem X”, and you are working with the team under that general manager, it is tough to tell that team that they are solving the wrong problem.  They really can’t handle that news, because they are not paid to question the directive.  They are paid to make it come to pass.


In this situation, traceability is a two-edged sword.  Traceability illustrates strengths, but it also illustrates weaknesses.  So if you ask the project team to tell you about the business goals, they will respond: the goal is to “Solve Problem X.” 

For the project team, there is no traceability above the directive.  No one can demonstrate traceability to anything that looks like business value or return on investment or business agility.  They are doing work because the big boss told them to.

The best that the project team can do is to try to find business value in “solving” problem X.  If there is far greater value in solving problem Y, and that simply makes problem X disappear, the project team will not be able to see their way there.  What’s an Enterprise Architect to do?

In those cases, you may be forced to do what I sometimes do: write down the assumptions that the team is taking, and NOT show your team how badly the assumptions trace to the business goals.  Just start with the assumptions and work from there. Your models will be wrong, but you will deliver output and build credibility.

Later, when you get a chance to present to the senior leader, don’t (just) talk about the (possibly wrong) results.  Talk about the assumptions.  See if he or she agrees.


To do this, you may need to produce many what-if models.  One that the project team has signed off on, and a couple that they have not.  When presenting to the senior leader, see if you can guide the conversation with the to consider alternatives, and then be ready to challenge the assumptions with real ideas.  You may not be able to convince everyone, but at least you will have had the conversation.  That is one of the most important things an EA can do. 

In this case, from the standpoint of the project team, traceability is not valuable.  If anything, it is counterproductive because it runs the risk of making them look like they are doing the wrong work.  But it is valuable in the end to make the enterprise successful.

Traceability matters to Enterprise Architects.  For some of our stakeholders, it is not valuable at all.  For a few, traceability is frightening.  For those stakeholders that won’t see value, don’t demonstrate traceability.  Traceability from goals to initiatives is a model that should not be shown to everyone. 

And that, unfortunately, is one tradeoff of being an Enterprise Architect.

Architects Working Alone

By |2010-01-05T18:11:40+00:00January 5th, 2010|Enterprise Architecture|

An old friend called me up today and shared a tale of woe.  He is a Business Architect, with years of excellent experience in Enterprise Architecture.  Yet, he finds himself in an ill-fitting role. 

According to my friend, who I will call Quincy, his manager doesn’t know what he does, and doesn’t value business architecture.  He has many peers, all of them share his title, all reporting to different managers, but according to Quincy, few of them are able to perform the job of Business Architect.   When it comes time for a review, he feels like there is no career path for him, and no consistent measure of value that he will be judged by.  Quincy feels unappreciated and alone.

I did my best to cheer Quincy up.  But in the end, he’s right.  It is tough to feel like your work is appreciated if your manager doesn’t understand it. 

Business architecture is not a trivial job function.  It is not something that the average business analyst can wake up one day and perform, or pick up with a two-day training course.  Business architecture, like any of the functions of Enterprise Architecture, requires specific skills, talents, and experience in order to deliver real value.  Like any profession, it takes time, training, mentoring, passion, and talent to develop into a high-functioning business architect.

Don’t get me wrong: people learn, and a well motivated person can grow into a well seasoned business architect in the right environment.  The job is tough, but not impossible.

Quincy can do the job… but he needs to feel supported, to provide value that is recognized by his superiors, and to have the ability to grow in his role.  This is a problem that many enterprise architects face when they are the only person in the organization with the title of “architect.”  They are alone, and ultimately, the machine of corporate life can wear them down. 

Over time, an architect, working alone, will take on other functions (like M&A integration, project management or even solution architecture) because those functions are both understood and appreciated.  The job title of “Business Architect” will lose relevance, and after a while, BA activity will end.

And this is why I believe that all of the folks in an organization that are responsible for any aspect of Enterprise Architecture, whether it is Business Architecture, Solution Architecture, Technology Architecture, Information Architecture or Process Architecture, should work for a small number of carefully chosen managers… people who understand the job that they do and the value that they provide. 

Sometimes those managers are in IT, sometimes they are in Finance, sometimes Operations, etc.  Wherever the right managers and support exist, EA should live there, even if it is not “ideal”. 

Otherwise, your architect is alone… and job satisfaction can suffer.  Just ask Quincy.

Read A Little Blasphemy

By |2010-01-03T13:01:00+00:00January 3rd, 2010|Enterprise Architecture|

Not an architecture topic, to be sure, but a human topic.  I am a firm believer in the freedom of expression.  I also believe that a peaceful world is born, in large part, of respect for the differences between people.  Without the ability to express differences, misunderstandings cannot be corrected.  Prejudices cannot be addressed.  As distasteful as it may be, it is important that we allow the misinformed people to write and speak and even attempt to teach things that we would consider wrong, or misleading, or even harmful.  As Voltaire is often misquoted in saying: “I do not agree with what you say, but I defend to the death your right to say it.”

As such, I find it perplexing, and seriously problematic, that the government of Ireland has seen fit to pass a new law that seeks to criminalize free expression in those situations where the speech offends someone’s religious beliefs.  I am talking about Ireland’s new Anti-Blasphemy law.  While there is clearly good intent in this law, I cannot support it. 

So what can we, the non citizens of Ireland who are offended by this law, do about it?  Continue, undaunted, to speak, and read, and share ideas… even mistaken ones… so that we will all learn together.  Were the Danish cartoons depicting muslims as terrorists an accurate depiction?  no.  But did the author and the newspaper have the right to publish them?  yes.  Did protesters have the right to picket, and governments have the right to react?  yes.  It is not wrong to speak.  It is not wrong to react.  It is wrong to kill, or imprison, or even fine someone, for speaking their ideas, and sharing them with others.

So, to my readers, I encourage you to take a moment and read statements from Mark Twain to Jesus that are now probably illegal in the beautiful and normally progressive nation of Ireland.  These statements are published on a web site hosted in Ireland, by a group of atheists who are challenging the law, so don’t delay because this site may vanish if the Irish courts decide to actually enforce this unjust law.

Read 25 Blasphemous Quotations at: http://www.atheist.ie/2010/01/25-blasphemous-quotations/

And while you are at it, find and read as many banned books as you can. 

You can find a list of banned books at: http://www.banned-books.com/bblist.html

(Note: I corrected the text above to reflect the fact that the cartoons were Danish, not Dutch.  Apologies.)