Inside Architecture

How organizations filter out change agents in their hiring process

Nick Malik — Fri, 10 Feb 2012 19:46:49 GMT

Hypothesis: One way to change an organization is to join it. Can we prove or disprove this hypothesis?

I had a long lunch with a friend of mine (whom I’ll call Joseph) who was interviewing at an analyst firm that freely shares opinions on Enterprise and Business Architecture, mostly from the E-I-T-A perspective. Joseph is a well-liked and well-respected Business Architect. I met him online and we have lunch every couple of months to catch up.

Joseph believes that Enterprise Business Architecture is not limited to IT, and he freely shared that opinion during the interview process. He was surprised at how well received he was in the early stages of the process. Could Joseph change the messages coming out of this firm by joining them? Could he change them from the inside?

What does a question say about an interview?

Joseph was not hired, and we spent lunch talking it out. Joseph was given a reason for being rejected. Reason: when he was asked this question: “what is the future of IT?” His answer was something that may have upset some CIOs. Joseph said that IT would have to change, because the cloud is an existential threat to traditional IT models.

While I’m not sure I agree with him completely, I do wonder why a Business Architect would be asked this interview question. Why would would an employer ask this question at all? It took a little thought to get to the answer, and I’ll share that thought with you in this blog post.

After we discussed it, Joseph and I agreed that the question said more than the answer. The question says a lot about change, and the ability of an organization to resist change from the outside. The question spoke volumes about the IT focus of the analysis company.

Going to the root cause…

Companies have business models, and each business model targets specific customers with specific services. Many analysis firms have a business model that specifically targets Chief Information Officers and IT leaders. Analysis firms succeed when they make the CIO happy.

The idea of Business Architecture is a two-edged sword for IT leaders. Business Architects who operate in the sphere of strategy execution are not operating in the traditional role of IT. Hiring a Business Architect is frightening, because it is an admission that IT may have to offer new services.

1960 MG MGA with installed seatbelt

Back in the 1950’s, the auto manufacturing companies had to decide whether to offer seat belts in cars. Some companies offered them as options, while others attempted to brand their products as “safe” by making seat belts standard. But the biggest resistance came from companies that didn’t want to offer seat belts at all. Why? Because offering a seat belt is an admission that riding in a car has risks.

Their thinking was this: “Our cars are safe, so we don’t offer safety belts. The other guys offer safety belts because their cars are not as safe as our cars.” It took years of scientific studies to disprove this nonsense. It took a lot of time for business leaders to make the mental shift from defending their existing ideas to adopting new ones.

Do we keep our customers happy, or prepare them for change

For a CIO to hire a business architect, they have to first admit that their IT division is not already able to perform Business Architecture services. They have to admit that a Business Architect is not simply a relabeled Business Analyst. They have to risk the possibility that the Business Architecture service will suggest, to the business, that they don’t need traditional IT services! True business architecture, at its most effective, must be able to conclude that the customer would be better off consuming fewer IT services.

Existing business models, from these analysis firms, are targeted to people who don’t want their staff to make those recommendations! To be effective at business architecture, analysis firms would have to change their business model to target business executives beyond the IT sphere. To make this leap, an analysis firm would have to offer new services, market to a new audience, adopt new sales methods, and produce new outputs, than they currently offer. That kind of change is difficult.

That is scary, not to the customer, but to the analysis firm. It’s a threat to the business model itself. So their response is to do what any company does when someone threatens the business model: get defensive! Their message must be “Mr or Ms CIO, Business Architects will support your idea of what IT should be” even when that is not in the strategic interests of the client company.

So this particular analysis firm wasn’t willing to hire Joseph. It’s a shame. He’s a good guy. I don’t always agree with Joseph, but I do listen to him. That said, after we talked it out, it made sense. They cannot hire Joseph unless they are willing to do one of two things: clip his wings, or expand their business model.

As the result of his experience, I wonder if the analysis firms can take a leadership role in moving the fields of Enterprise and Business Architecture forward. For a while, I thought that they could. Now, I’m not sure.

Hiring processes filter out change agents

I started this post with a hypothesis. Can you change an organization by joining it?

From this single example, I’d say that the clear answer is “not always.” If a company is good at filtering out the people who could lead them to a new business model, then they won’t let you in the door. Of course, once you are in, there are even more internal forces that would present an obstacle to adopting a new business model.

When you consider all these obstacles, perhaps the real question: if you want an organization to change, what’s the most effective way to change it. Joining the company may not be the best way to do it. Consider other ways.

Technorati Tags: business model,change agent,hiring process,business architecture,IT analysis,enterprise architecture

Creating a Core Diagram for Agile Business

Nick Malik — Wed, 01 Feb 2012 00:47:17 GMT

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:

What is a core diagram and what should it contain?
Who cares about a core diagram and what are the scenarios for use?
What is Minimum Sufficient Business Integration (MSBI) and when should this method be used?
Step-by-step instructions for the MSBI method and outputs produced
Testing and Landing the core diagram in your business and governance processes

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:

Open Group Presentation on MSBI method of creating Enterprise Architecture Core Diagrams

View more presentations from Nick Malik.

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

Nick Malik — Fri, 13 Jan 2012 22:34:29 GMT

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.

A Modern Update to The Blind Men and The Elephant

Nick Malik — Wed, 11 Jan 2012 10:38:01 GMT

My humble apologies to John Godfrey Saxe, whose poem I have modified to add a seventh man, and to make a point…

‘twas seven men of Indostan
To learning much inclined,
Who went to see the Elephant
(Though all of them were blind),
That each by observation
Might satisfy his mind.

The First approach'd the Elephant,
And happening to fall
Against his broad and sturdy side,
At once began to bawl:
"God bless me! but the Elephant
Is very like a wall!"

The Second, feeling of the tusk,
Cried, -"Ho! what have we here
So very round and smooth and sharp?
To me 'tis mighty clear
This wonder of an Elephant
Is very like a spear!"

The Third approached the animal,
And happening to take
The squirming trunk within his hands,
Thus boldly up and spake:
"I see," quoth he, "the Elephant
Is very like a snake!"

The Fourth reached out his eager hand,
And felt about the knee.
"What most this wondrous beast is like
Is mighty plain," quoth he,
"'Tis clear enough the Elephant
Is very like a tree!"

The Fifth, who chanced to touch the ear,
Said: "E'en the blindest man
Can tell what this resembles most;
Deny the fact who can,
This marvel of an Elephant
Is very like a fan!"

The Sixth no sooner had begun
About the beast to grope,
Then, seizing on the swinging tail
That fell within his scope,
"I see," quoth he, "the Elephant
Is very like a rope!"

And so these men of Indostan
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong,
Though each was partly in the right,
And all were in the wrong!

Silent was the Seventh man
Who heard the heated fray
Not touching the amazing beast
Upon that fateful day
Chose wisely to collect his clues
From what each had to say

Concluding from the evidence
That no man clearly knew
The seventh man did not attempt
To posit what was true
Instead he sought to ascertain
what the beast could do

Tried and failed, and tried again
This man did ply his art
Invented he, a harness great
And cried out from his heart
“I cannot see the shape of it
but it sure can pull a cart!”

MORAL

So oft in theologic wars,
The disputants, I ween,
Rail on in utter ignorance
Of what each other mean,
And prate about an Elephant
Not one of them has seen!

The wise, instead, do not delay
to overcome their lack of vision
They absorbs, from fellow men, their
thoughts and intuition
And then they act to journey forth
accomplishing their mission

Wikipedia’s EA article, second pass

Nick Malik — Wed, 04 Jan 2012 10:39:50 GMT

After a rather protracted discussion on LinkedIn about the Wikipedia article on Enterprise Architecture (blogged here), I took another swing at rewriting the EA article’s opening section. It is far from perfect, but I encourage the folks who have been following this discussion to take a look.

The change I made was fairly straight-forward:

- Removed unverifiable definition of EA

- Added three verifiable definitions from three perspectives:

EA as a business practice,
EA as the desired level of integration and standardization in an enterprise, and
EA as a set of artifacts.

- followed each definition with a layman’s interpretation of that definition.

Normally, I would argue against actually citing a definition in a Wikipedia article. After all, it is an encyclopedia, not a dictionary. That said, after long and protracted debates about the meaning of the word ‘enterprise’ and the meaning of the word ‘architecture’ and the derivation of the term ‘enterprise architecture,’ I decided to break the rules a little and actually quote from the definitions themselves in the Wikipedia article. This is really unusual, and I expect that I may get pilloried for it, but after all the arguments, I didn’t want anyone to tell me that I had interpreted their definitions “incorrectly” by quoting original sources.

The new opening text of the Wikipedia article on EA is:

The term enterprise architecture is used in many complimentary ways. It is used to describe both a unique business practice and the aspects of a business that are being described. The Enterprise Architecture Research Forum defines the practice of enterprise architecture as follows:

Enterprise Architecture is the continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change.[1]

In simple terms, Enterprise Architecture is a self-improvement business function that examines the structure and behavior of the various parts of an 'enterprise' and focuses on opportunities to improve it.

The MIT Center for Information Systems Research (CISR) defines enterprise architecture as the specific aspects of a business that are under examination:

Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company's operating model. The operating model is the desired state of business process integration and business process standardization for delivering goods and services to customers.[2]

Simply put, the enterprise architecture in an intentional vision that defines how business processes should be integrated and where process standardization should be used.

The United States Government describes enterprise architecture as an Information Technology function. Instead of describing enterprise architecture in relation to the practice of examining an enterprise, the U.S. Government defines the term to refer to the documented results of that examination. Specifically, US Code Title 44, Chapter 36, defines enterprise architecture as a 'strategic information base' that defines the mission of an agency and describes the technology and information needed to perform that mission, along with descriptions of how the architecture of the organization should be changed in order to respond to changes in the mission.[3]

Practitioners of EA call themselves enterprise architects. An enterprise architect is a person responsible for performing the complex analysis of business structure and processes and is often called upon to draw conclusions from the information collected. By producing this understanding, architects are attempting to address the goals of Enterprise Architecture: Effectiveness, Efficiency, Agility, and Durability.[4]

Customer 2.0 Strikes

Nick Malik — Wed, 28 Dec 2011 09:52:56 GMT

For those folks who don’t normally track the events of the Gamer community, I’d like to share a lesson that every consumer facing business should heed. Social Media has changed the consumer landscape in an irrevocable way. This incident demonstrates what happens to companies that don’t understand the new power of the customer.

In short, a small manufacturer hired a marketing company to promote it’s novel product. Unfortunately, the marketing company failed to correctly handle the import paperwork, and the product was stuck in customs. Customers who ordered the product for Christmas were not going to get their product in time.

As you’d expect, some customers complained. One in particular known only as “Dave.” The marketing company made a couple of rather typical mistakes in handling the complaint. The customer threatened to get the press and social media involved. At that point, the company blew it. Instead of taking a contrite and apologetic tone, offering to reduce the stress of the customer or even offering a discount on the order, the company representative sent a profane and inflammatory e-mail directly to the customer telling him, basically, to “get over it.”

That customer shared his e-mail with social media, and the storm started. Within hours, the manufacturer has fired the marketing company. The marketing company has been banned from at least one influential show (and my guess, the fallout won’t stop there). The company’s image is in the toilet. If they are still in business in a year, I will be amazed.

The business world has changed. Customers have the power of community, and can act in groups in a way that they could never act before, at a speed that will make your head spin. Companies who do not understand this fact will be left behind.

Wikipedia and the definition of Enterprise Architecture

Nick Malik — Tue, 13 Dec 2011 22:27:15 GMT

I was asked, this week, about a page that I had put into Wikipedia nearly three years ago. Far from being able to take credit for it, I discovered that many of the edits made since I put the page up corrupted it to the point of uselessness. Alas, after changing that page back, I checked out my favorite page: Enterprise Architecture.

And it was unrecognizable.

The entire page had been rewritten by a single person (Matthew Kern) who, apparently, believes that “Enterprise Architecture” == FEAF (The US Government EA Framework). While I applaud Mr. Kern’s desire to include cited sources for his statements, his decision to ignore all of the prior content and contributions and toss out all of the compromises along the way seems both short-sighted and arrogant, to say the least.

I endeavor to let the current author settle a bit, and then change most of the article back, but for the sake of documentation, I wanted to share the direction that Mr. Kern wants to take the Wikipedia article on EA. Gentle readers, do you agree with Mr. Kern’s decision, or do you support my intent to revert to the original material?

Previous Opening Section (compromise text)

New Opening section

An enterprise architecture (EA) is a rigorous description of the structure of an enterprise, which comprises enterprise components (business entities), the externally visible properties of those components, and the relationships (e.g. the behavior) between them.

EA describes the terminology, the composition of enterprise components, and their relationships with the external environment, and the guiding principles for the requirement (analysis), design, and evolution of an enterprise.

This description is comprehensive, including enterprise goals, business process, roles, organizational structures, organizational behaviors, business information, software applications and computer systems.

Enterprise architecture (EA) is a term first used in print in NIST SP 500-167 a US Federal Government Document from the National Institute of Standards and Technology) in 1989. It is currently a mandatory practice in the US Federal Government: OMB Circular A-130 describes enterprise architecture and subordinate activities in some detail, in response to the Clinger Cohen Act (IT Management Reform Act) of 1996 mandatory requirement for government organizations (enterprises) to have an "IT architecture". The term has subsequently (after first use in 1989 by the US Federal Government) been used in foreign governments and in commercial practice.

According to the U.S. Federal Government: "An EA is the explicit description and documentation of the current and desired relationships among business and management processes and information technology. It describes the "current architecture" and "target architecture" to include the rules and standards and systems life cycle information to optimize and maintain the environment which the agency wishes to create and maintain by managing its IT portfolio. The EA must also provide a strategy that will enable the agency to support its current state and also act as the roadmap for transition to its target environment. These transition processes will include an agency's capital planning and investment control processes, agency EA planning processes, and agency systems life cycle methodologies. The EA will define principles and goals and set direction on such issues as the promotion of interoperability, open systems, public access, compliance with GPEA, end user satisfaction, and IT security. The agency must support the EA with a complete inventory of agency information resources, including personnel, equipment, and funds devoted to information resources management and information technology, at an appropriate level of detail."

What say you?

Technorati Tags: Enterprise Architecture,Wikipedia

Using Enterprise Architecture To Get The CIO To The Strategy Table

Nick Malik — Mon, 21 Nov 2011 20:33:10 GMT

Recently, Patrick Gray blogged on TechRepublic that IT has a Chicken and Egg problem. In his post, he describes two mechanisms that CIOs take to become recognized as strategic leaders: a) work in anonymity to demonstrate that the work that they are doing is aligned, hoping someone will notice, and b) wait for the business to take on the responsibility for ensuring that IT’s efforts are aligned. He charts out a course that involves a) get the utility aspect perfect, quietly, b) speaking the language of business value, and c) pitch the strategic expertise of IT.

Reasonable advice in some ways but, as always, the devil is in the details.

Getting the utility aspect perfect is NOT a prerequisite. Having IT to the point where it works reasonably well is sufficient. Executive peers should not be distracted by bad service, but perfect service is an unattainable goal. All services have tradeoffs, especially with respect to “time to market” and “cost.” There is no one else at the executive table that has a perfect operational aspect. Marketing sometimes runs an ineffective campaign. Sales sometimes misses their targets. Operations is not perfectly efficient and effective. Customer support sometimes angers a customer or two (or ten). Perfection is not necessary.
Speaking the language of the business can be tough when “the business” does not speak the language of business. Read that twice. The “Language of business” is not just dollars and cents. It is often influence, power, and politics. This requires an understanding of not only the language of “value” but also the language of “power.”

How many times has a “business client” of IT asked for a project without any rational reason for believing that the project is actually a good expenditure of money? How many times has a good, valuable project been cancelled or poorly funded while a pet project moved ahead. The language of “value” is necessary, but not sufficient, to get business peers to include you in critical conversations. They have to believe that they need your resources, your input, and your power to deliver. For the CIO to exercise power, he or she must first have it, and then must demonstrate it. I’ve seen many who either did not, or could not, do that.
The strategic expertise of IT is interesting, but where exactly is IT exercising that muscle? Why would IT have any strategic expertise at all, unless it is carefully developed and encouraged. And what exactly would a strategic capability within IT look like?

Enterprise Architecture is a business function that allows the business to do a very important thing. EA is based on the simple rule: “Do what you say you will do.” Many a business executive will declare that they can’t actually get the business to do what they want it to do. EA is part of the solution to that problem. It is a necessary business function. The leader who owns this function has an “ace” to play. And if that leader is the CIO, then the CIO has a useful capability.

Patrick Gray is right… you must not “live” with the hand you are dealt. You must build a better hand. Enterprise Architecture is one card that the CIO can build into his or her hand, and then play to great effect.

Technorati Tags: Enterprise Architecture,CIO,alignment

The End of Flash

Nick Malik — Wed, 09 Nov 2011 20:37:58 GMT

The writing is on the wall. Adobe has abandoned Mobile Flash in favor of HTML5. It is just a matter of time before the Adobe Flash developers switch over to producing HTML5 instead of Flash as a matter of course. With the move to mobile devices, the dominance of Flash on the desktop will simply not matter anymore.

I’ve been in this profession for 31 years. I’ve seen a long list of technologies rise up to be one of the “top technologies” in a space, only to be relegated within a few years to the dust heap. There is always a tipping point. Apple pushed, and now, Adobe tipped.

It is time to add Flash to the list.

To create a roadmap, we need to know what it is supposed to accomplish

Nick Malik — Fri, 04 Nov 2011 22:16:22 GMT

I’ve been involved in a number of meetings recently as our IT teams try to come to consensus on answering this question: What is a Roadmap? It’s been a fascinating series of discussions. One thing that strikes me is that most of the internal discussions, and many of the discussions I’ve seen online, are only seeing part of the business process where a roadmap is used.

If we don’t see all the process interactions, we can’t get the requirements right. And if we don’t get the requirements right, the solution (the design of the roadmap) will not be as useful as it could be.

[Terminology Note: I don’t have any great love of the word “roadmap” to refer to the EA artifact. I like “action plan” as a term, but I have no strong preference. In keeping with prior posts on the subject, I’ll keep using the word “roadmap” unless and until we can get some consensus on an alternative word.]

Picking the correct approach

There are two different business processes where a roadmap is useful: deciding on the order of efforts, and tracking the efforts against that decided order. IT folks tend to focus on the second. I will focus on the first.

When we look at the notion of strategic planning from an EA perspective, we are trying to reduce unnecessary effort. Just as a downhill skier in the Olympic games will surely lose if they are off course by a few degrees, adding a few extra meters to the length of their run, commercial enterprises are not asking for “any path down the hill” to win the race. They are asking for “the best possible path down the hill.” (If your company is run by a salesman, they may shout the words “win the race.” :-)

The business has created their strategy and we have assisted with creating the measurable scorecard to track our progress towards achieving it. That is step one (most Enterprise Architects have NO idea that this is part of their job).

The first process that uses Roadmaps starts here (colored in brown above). Enterprise Architecture collect information to produce a series of alternative approaches (“candidate roadmaps” in the diagram above). The input information includes other roadmaps, as well as business rules, political needs, dependencies, parallel initiatives, resource constraints, technology standards, fiscal constraints, regulatory constraints, and business drivers. Each approach allows the business to deliver on that strategy in a way that is feasible, fiscal, and forward looking. We allow ideas that may require us to change big things (merge, split, and repurpose teams, systems, processes, assets, etc.).

Why have many candidates? Because there is nearly always more than one path. Each path will have tradeoffs. One may be quicker to see results, another less expensive, and another less disruptive to existing product plans. We need the business to pick the path that they want to follow. Moreover, we want them to debate the tradeoffs in front of their peers, and come to a resolution about which path they will collectively select. Because the only thing worse than having no roadmaps is having many competing roadmaps. It is tempting to come to the business with only one roadmap. “Here’s your solution, sir.” On occasion, that works. Depends on the organizational politics. Personally, I think that is not a good recipe for buy-in. Your mileage may vary.

At the end of this two-step process, we walk out of the room with something powerful: buy-in. We come away with a clear decision: beyond “get this done,” we now have “go do these projects, in this order, to get it done.”

The candidate roadmaps fuel the debate. It is the tinder to which we strike a match. Each one explains all of the information that a stakeholder needs to debate the pros and cons, and the collection of information is sufficient to allow business leaders to pick one with their eyes open to the tradeoffs.

Delivering on the approach selected

In the second part of the process (in purple above), we bring up the roadmap on a regular basis as we review, with our business stakeholders, the status of our projects and whether there are dependencies that may be driving our decisions. In other words, if two projects are on time and a third project is late, but the fourth project cannot kick off.... You get the picture.

This is a kind of decision-rich governance activity. The “roadmap” in this context is used for expectation management. While this is a very valuable activity, you do NOT need all the same data for this activity as you do for the previous one. Whether you need one diagram or two will depend on your business and how it handles project governance.

Conclusion

I went to such trouble to explain the distinction between these two parts of the process because the first part (using a roadmap as a high-level decision making tool) is often misunderstood by EA stakeholders who only view EA from an IT context. As such, much of the debate on “what belongs in a roadmap” is centered around delivery needs and not enough on the decision needs described above.

To build a better roadmap, it helps to know where it will be used.

Governance in an Organic Enterprise

Nick Malik — Wed, 28 Sep 2011 11:32:12 GMT

I spent a few minutes this evening reading through Tom Graves’ fascinating post Management as ‘just another service’ and it got me thinking of Governance in the organic enterprise.

As Tom describes, there are two paradigms of management at play: organization as machine, and organization as living organism. Tom is of the opinion that most organizations think that they are of the first type, while they actually behave like the second type. While I cannot quantify his assertion, I have noticed that my own organization behaves more like an “organization as living organism.”

So, this evening, as I contemplate the notion of enterprise governance, I consider the reality of improving governance in an organization that behaves more as an organism than as a structured automaton. In order to share my thoughts, I want to establish some basic terms to make sure we are all on the same page.

First off: Governance is a system of distributing decision rights to specific individuals or groups so that (a) desirable behavior is encouraged, (b) undesirable behavior is discouraged, and (c) business rules are aligned with enterprise principles and legislative constraints. Governance can be a simple as having the project sponsor review the project plan, and as complicated as having the United States Supreme Court review the specific clauses of President Obama’s healthcare reform law, before the administration compels the various states to implement it.

There are many things that can be governed: the scope of projects, the expected architectural outcomes, the assignment and activity of individuals, the assignment of responsibilities to teams and systems, the correct handling and security of information, and the measurable performance of processes, to name a few.

In addition, there are many different levels at which governance occurs. Governance can occur at the personal level (I choose to do the right thing). It can also occur at any “level” where a group of people with specific decision rights have a stake in the governable elements of an activity. To whit:

A team may want to govern the efforts of its members.

A business sponsor may want to govern the activities of a project team that is spending his or her money.

A cross-business virtual team (v-team) may want to insure that dependencies between teams are carefully managed in order to insure the delivery of value.

A senior business executive may want to govern the level of acceptable risk in a portfolio of projects to insure that there is a good balance between innovation and incremental improvement.

A senior leadership team may want to insure that leaders have clear ownership and accountability (no gaps or overlaps) so that strategic changes can be implemented in cross-functional processes.

This may lead you to conclude that governance can be performed as part of a hierarchical escalation process, but that is not a foregone conclusion, as you will see below.

When designing a system of governance in an organic enterprise, we need to make sure that the “solution” matches both the “problem” and the organizational “network of influence” (instead of hierarchy) that the enterprise uses to make decisions and resolve disputes.

So let’s break down the problem a little. What is the array of problems that organizational governance (of which IT governance is a subset) is supposed to solve? Here are some elements of that array:

Senior leaders are consulted when the cost of day to day operations overwhelms the organization’s ability to behave strategically
Business Managers are consulted when investments by one business manager can interfere with the efforts of another
Process owners are consulted as a process is being changed, leveraging organizational knowledge and experience
Information facet owners are consulted as requirements emerge that impact master data management and data quality
Platform owners are consulted for the improvement of business capabilities supported by enterprise platforms
Architectural owners are consulted as system designs are considered for inclusion in the enterprise IT ecosystem
Organizational standards are followed in order to minimize the cost of ownership of process, system, information, and infrastructure investments

The key thing to note from this list is that different “governors” are interested in governing different things. There is no simple “chain” of escalation. Rather, it is a network. This is one effect of organic governance. Another is that the number of levels of governance, for any one issue, should be fairly short. You deal with things at an individual level, at a project level, and then, fairly quickly, at the level of a “governance body” designed specifically to resolve that particular type of issue for a business and then the enterprise. Lastly, there is a senior management body that can settle all remaining disputes.

Unfortunately, when considering this kind of problem, the metaphor of “enterprise as organism” begins to fail. Actors in an enterprise do not behave like cells in an organism, nor do business units within an enterprise behave like organs. Cells are regulated by internal instructions, hard-coded in chemical DNA sequences, and respond to fairly simple stimuli with pre-programmed responses. Actors and business units do not.

Organizations do not have consistent and uniform instructions (like DNA) that guide each person and business unit. Governance is needed because of the variation of human beings and their desire to continuously look after their own interests. Quickly we can see that the “organism” metaphor is shaky at best. In small units, the metaphor of a sports team is a better metaphor, and at the larger end, the metaphor of a city is more appropriate.

I work in a fairly large company, so the metaphor of a city is better for me to consider. After all, I’ve lived in cities all my life. So in a city, how many times have I behaved in a beneficial way? I’d like to believe that I do that every single day, in a hundred small ways. How many times have I interacted with the police? Less than the fingers on one hand. Well… that’s interesting. That simple observation alone makes one thing starkly clear: the police do not govern my city life.

I believe that the most important governance element of city life is the system of property laws, commercial practices, licensing laws, and simple rules of civil behavior that allow the city to be a productive and useful environment for individual people. Governance itself is a tiny fraction of the overall efforts of the population of a city, and it is normal to live your life for years without involving a police officer, filing a law suit, or walking into a court. That said, courts and lawyers and legislative bodies are essential overhead. From an economic standpoint, governance is overhead and waste. People who govern contribute nothing. But from a social standpoint, the system of governance is critical to the success of the “organically” managed city.

Which leads me to a rather startling conclusion: In order for a large organization (of say 100,000 employees) to successfully becoming a mega organization (of say 1,000,000 employees), they must develop a simple and fair system of property laws, commercial practices, licensing laws, and rules of civil behavior, and a simple adjudication system to address conflicts. Hierarchy does not work as a model of governance in an organic enterprise.

Technorati Tags: Enterprise Architecture,Corporate Governance

When IT Architects Describe EA to other IT Architects

Nick Malik — Fri, 02 Sep 2011 16:53:24 GMT

Sometimes, I have a hard time being upbeat about the emergence of EA as a profession. This felling is especially acute when I come across a slick, well-prepared guide to Enterprise Architecture, written by an IT Architect, that is incomplete, inaccurate and/or misleading. That happened to me today.

The guide is written by Wolfgang Keller and was published in its final form in November of 2009. His guide is titled “TOGAF 9 Quick Start Guide for Enterprise Architects.” The document can be found here.

Most Enterprise Architects have their roots in IT organizations, and there is a great deal of interest in both the role of EA and the TOGAF framework’s stated goal of becoming a framework useful for Enterprise Architecture. That said, most practicing Enterprise Architects have some level of difficulty applying the TOGAF to their work, largely because it is a guide to producing Enterprise IT Architecture (EITA) artifacts, and not EA artifacts. One such architect, Adrian Grigoriu, writes about his experience applying TOGAF to EA in his blog (link).

EITA is to EA what a Biologist is to a Physician… a respected colleague with a similar area of concern, but totally different role. Since TOGAF is a framework for EITA, it can be tough to expect an EA to use it. Now, I know that the Open Group is making progress, and I have acknowledged that progress in past posts. But let’s face it: TOGAF is about 20% there. It is not wrong… just wildly incomplete. Learning TOGAF to do EA is like learning to fly a business jet in order to take on combat missions in an F16. The skills you’d gain are somewhat useful, but not even close to being sufficient.

So when I opened up Keller’s guide, I expected to see some tables showing typical scenarios for an Enterprise Architect, the ways in which a framework can support EA, and an indication of the gaps that TOGAF still has in providing that support. That is not what I found, and I’m not happy with what I saw.

First: it was not written by an EA or even listing EAs as contributors. There is no indication whatsoever that the author actually has ever worked as an EA. It would be like a nurse writing a guide to the Physicians Desk Reference. Worse, “experienced” Enterprise Architects are supposed to use this. What does it say about the student if he chooses a fool as his teacher?
Second: The author describes Enterprise IT Architecture, not Enterprise Architecture. He doesn't know, nor has he taken the time to find out, what an Enterprise Architect actually does. It is one thing to be speaking outside one's area. It is another to describe the role in completely inaccurate terms.
Third: The author, while attempting to describe the much more limited role of EITA, gets that wrong as well. The author has placed the role of EITA in an untenable and ineffective position with no authority (or even role) in program portfolio prioritization and funding. If that were my job as an EITA, I’d quit. I have seen EITA’s struggle and fail, time and time again, in this role. This makes the guide not only a bad way to access TOGAF, but also provides some elements of seriously bad advice for any IT architect.
Fourth: His document misrepresents itself. Only about one third of it is a guide to using TOGAF. There are two other parts. One is a description of software architecture (including a history lesson), and the final third is a supplement that attempts to fill in some perceived gaps in TOGAF. He attempts to address two specific gaps: Formulation of IT Strategy, and IT Portfolio Management. He makes an attempt in both cases, and I will credit him for the effort. The output is average. Were TOGAF to include his supplement sections, it would be helpful to a small number of EITA’s, but not any EA’s that I know.

There are two use cases for reading the document, outlined by the author: (a) An Experience EA wanting to understand TOGAF, and (b) A Student wanting to learn EA and TOGAF. For both cases, the guide fails to be practical and, in many ways, is actually harmful. I cannot recommend this document for either case.

Of course, that means that there is still an opportunity for an actual Enterprise Architect to do what Adrian tries to do, and provide insight into how TOGAF can be used to in the practice of Enterprise Architecture.

If you know of one… please let me know. If you develop one, I’ll be happy to review it. (If you’d like my feedback to be private, let me know before you publish it and I will do what I can to provide feedback in a timely fashion. Once it is published, my feedback on the published version will be public as well.)

Technorati Tags: Enterprise Architecture

Explaining Capability Modeling to Business Process Professionals

Nick Malik — Fri, 19 Aug 2011 18:53:05 GMT

As I’ve noted in prior posts, many hard working business process management professionals find the concept of “Business Capabilities” to be confusing at best, and counterproductive at worst. In a recent article in BPTrends, Paul Harmon made the following statement:

the idea of "capabilities" is introducing confusion into the marketplace. It is hard enough to work with an organization to create a business process architecture that can be used to effectively organize the management and measurement of how well the organization is achieving its goals. To introduce the idea that an organization should first or simultaneously create a map or hierarchy of "capabilities" and then create another hierarchy of processes is to add confusion to an already very difficult and complex task.

This confusion is well known to me. Within Microsoft, we have a very strong group of senior professionals who base their efforts and practices on BPM concepts. This includes Kaplan and Norton’s Balanced Scorecards, as well as methods like Six Sigma, Lean manufacturing, and Total Quality Management.

BPM is my world too. As readers of my blog know, I am fortunate enough to consider myself to be a follower of these same ideas, having been exposed to TQM while I was working at IBM almost 20 years ago. I’ve worked at many levels of process improvement.

At the business level: I’ve worked to convey the need for process improvement and help the stakeholders feel comfortable with methods,
At the modeler level: I’ve worked to collect the ideas of stakeholders and map out both current state and future state,
At the analysis level: I’ve worked to take models and analyze them for opportunities, target waste, and develop innovative alternatives, and
At the technical level: I’ve implemented a number of BPM systems and even wrote one of my own.

That experience lets me have a good relationship with both my EA peers and my BPM peers. I’m aware of both approaches, having done both. As my readers may also know, I use business capability models in my daily work. I create models of capabilities that are useful, valuable, and understandable. I know the value of capability modeling.

When I talk about business capabilities with my peers, I have to be careful. Business capabilities are poorly explained and poorly socialized. It can be tough to convince a BPM professional to listen to these “radical” ideas when we, the community of architects and analysts who also use business capabilities, have communicated so inconsistently about them.

First off, let’s look at the environment we work in.

Business process management practices and techniques are widely used. In many cases, they have produces very valuable results. However, the field is still quite young. As in any young field, there are failures as well as successes. I’ve seen projects succeed, and been quite proud of them. I’ve also seen projects attempt to use BPM practices, waste time and money, and produce no real result. The team would usually deliver something, but often that delivery occurred in spite of the process efforts, and not because of them. Like any tool, using it well produces good results, and using it poorly… doesn’t.

Let’s start with a problem

We all have to solve business problems. Sometimes, you need to approach a problem one way… and sometimes a different approach is called for. Business process modeling is a powerful tool. Business capabilities provide an additional tool. Sometimes you need to use them.

Let’s look at one of those times.

Joe Freeflier is a business manager in the finance group of his large company. The company has five divisions, each with completely different business models. The divisions operate quite independently of one another. They don’t share the same sales force, and they don’t really speak with the same customers. Each division has its own plants, and its own workforce. Joe, unfortunately, works for corporate.

You see, Joe is responsible for maintaining a set of business controls, as well as insuring that each division’s revenue recognition systems and processes are compliant and auditable. He can see how the transactions appear on the general ledger, but he also has to make sure that some basic rules are followed in order to insure that the company is behaving in a legal and responsible manner.

Joe has a couple of teams. One team is focused on a large merger that the company went through in January. His team is working with this new business to merge their financial systems with one of the existing divisions. Another team produces important reports for the senior staff, some of which feed the quarterly corporate reporting required of publically traded companies. A third team performs spot audits and works with the divisional finance leads to insure smooth reporting all up. Joe’s customers are really the divisions themselves… and each of those divisions have their own business processes.

Joe needs some help. The new merger has caused some churn. His team is having a hard time working with the new business unit, and his manager has told him not to “govern them out of business.” Now, Joe meets every month with Jürgen, his contact from IT, and at one of those meetings, Joe vents about his current problem. Jürgen suggests that Joe speak with his business architect Sally, and a meeting is arranged.

Sally spends some time working with Joe to understand his concerns, and now has two choices. She can suggest either a process-centric approach or a capability centric approach. Sally does not know if the problem can be fixed with a business process change. She doesn’t know if the tools need to change, or the policies need to change, or the information collected needs to change, or if it is a training problem. She just knows that Joe needs help. Let’s walk through her thinking:

Process centric:

Sally knows Joe’s business goals and the controls he needs to insure. She proceeds to spend time with each of Joe’s divisional customers to map out their business processes, making sure that she is fairly accurate yet high level. Three of the divisional teams have never mapped out their processes, but one has. She starts there, and the process looks like a standard she is familiar with. Unfortunately after interviewing some of the staff in that division, it is clear that they don’t actually follow that particular process. So she falls back to a standard definition from an industry group, and spends a couple of meetings getting everyone to the same very-high-level process model. Ten weeks have gone by, but she’s made some progress in understanding the landscape.

Now, Sally visits the newly merged team and spends some serious time understanding what their existing process is, and how it may be different. She finds that their business is based on a kind of “consignment” financing mechanism, and the revenue recognition processes that Joe uses have to be able to handle a number of new business events that he never dealt with before. So she returns to speak with Joe about tracking these new events, and trying to fit the new financing mechanism into his controls. Joe puts two of his team onto a small project to craft an alternative set of controls, while the IT team begins to look at new data pathways needed in their financial system. As it turns out, Joe doesn’t need to change his processes… what he needs is to change the way information is collected to adapt to new processes. Joe creates his controls, and creates a set of IT requirements for the IT team to fulfill. Sally is done.

Sally was successful, and her effort took about four months to do. Along the way, she learned a great deal about the financial processes, and four divisional leaders now have a process model for their work. Remember that three didn’t feel the need to create one before, and the fourth didn’t use their model. Six months later, none of them refer to the process model at all, and it has become “shelfware.”

Capability centric:

Sally knows Joe’s business goals and the controls he needs to insure. She spends a few days working intensively with Joe. She has a capability taxonomy that she brought with her from another project. Her first goal is to get a small list of capabilities that Joe sees as valuable. After about three or four days, she has a list of capabilities that his team needs to perform in their duties. These capabilities are “bits of process” that his team owns and needs to do consistently, regardless of the higher-level processes that his customers use. They are the “standard parts” of processes that his customers have taken a dependency on him to perform well.

Now, Sally visits the newly merged team and spends some time understanding what their overall process is. Note: Sally is looking at their process! She looks to see whether the new unit would benefit from Joe’s finance team and looks for ways to plug Joe in. It becomes immediately apparent that Joe has some expectations that won’t fit their business. The new business is based on a kind of “consignment” financing mechanism, and Joe is assuming a more traditional supplier-retailer business relationship. So Sally comes back to Joe and asks him for details about his assumed business processes. She works with Joe for another week, charting out a narrow slice of business processes from Joe’s point of view. She then goes back to the new unit and maps out the same narrow space on a process model.

She presents these two process maps to Joe, who now understands the problem. Joe puts two of his team onto a small project to craft an alternative set of controls, while the IT team begins to look at new data pathways needed in their financial system.

Both methods got to the same result.

The capability effort got us there much faster. Using business capabilities to identify the problem, and narrow the focus of the team, Joe was able to get his team to solve the problem within about four weeks of Sally’s arrival. She didn’t have to meet with the divisional leaders even once, and she didn’t produce an all-up process model. Had she stuck with the process-based approach, it would have take three times that long. Along the way, the process approach produced an interesting model, but it was not later used by anyone.

Note that, according to Lean manufacturing, the intentional creation of an output that is not actually used by anyone, is waste. The use of capabilities allowed Sally to remove the wasteful act of creating a high-level process model.

What I did not do

I did not answer the question: “what is a capability?” It was not my goal, in this post, to answer that question. My goal is to show my friends that a tool produced a good result. If my friends want to use the tool, defining it is unnecessary. If my friends don’t want to use the tool, defining it won’t matter.

Did you learn what a hammer was by having someone define it to you, or by swinging at a couple of nails?

Was this a contrived example?

It was an example derived from experience. That said, there are equally compelling examples where using the word “business capability” generates confusion. If Sally had gone to the new business unit and had said “I know you look at things as end-to-end processes, but I want to introduce you to the concept of business capabilities,” then she would have failed in her job as a business architect. Sally could no more use capabilities with the new business unit than she could have taught a teenager to drive by teaching him how to overhaul the transmission.

Capabilities are a complexity. Some business stakeholders live at that level of complexity already, and they WANT to work at that level. For them, capabilities make sense. Other business stakeholders live at the highest levels of end-to-end experiences. For them, capabilities make no sense at all.

Technorati Tags: business process management,business architecture,capability modeling,process modeling,enterprise architecture

Enterprise Business Motivation Model version 3.5

Nick Malik — Wed, 27 Jul 2011 07:26:07 GMT

For those of you who have been waiting for me to announce the release of the newest version of the Enterprise Business Motivation Model, I’m happy to announce that version 3.5 is available now.

To visit a Wordpress site set up to explain the model, visit http://motivationmodel.com

To visit a web site produced by the Sparx modeling tool, allowing direct navigation of the model itself, visit http://motivationmodel.com/ebmm

To download a PDF document exported by the modeling tool (for those folks who love PDF files), visit this link here.

Special Thanks

The Enterprise Business Motivation Model has gone through a long list of changes since the original article was published over two years ago. I’ve spent considerable time working through the model and getting feedback from colleagues from around the world.

I’d like to give special thanks to Michael Davison, JD Beckingham, Neil McWhorter, Bruce McNaughton, Henk Harms, Bill Ulrich, Jim Rhyne, Kirk Rheinlander, Leo de Sousa, Yelena Edelstein, Al Newman, Amy Nguyen, David Vugteveen, and many others who have commented, criticized, and asked for clarifications. Without your concerns and your insight, the EBMM would not move forward. Thank you!

Changes to look for

There are many changes since the last public version (v1).

The business model description was updated to reflect connections between customer types and partner types, and to more completely cover the model elements of Alexander Osterwalder’s Business Model Generation. (model, description)
Porter’s Five Forces was added as a separate area clarifying the linkage between a Five-Forces analysis and business models themselves.
The dual notion of Business Capability and Business Unit Capability proved too confusing and arbitrary for a core conceptual model. The single concept of Business capability remains.
The concept of Data object is now elevated to a top-level element in the model with necessary changes to the high level view.
Business role was added with relationships to business processes and data objects.
The concepts of Regulations, Legislative Edicts and Charter Legislation were added to clarify the role of these key concepts to Government and Semi-private organizations.
The concept of “capability maturity” was expanded to “assessment metric” to allow a broader understanding of how measures can be applied to business capabilities in order to motivate and measure the success of initiatives.
Clear distinctions are made between an enterprise, a company, and a business.
An additional relation has been added to business unit: relates to. This allows models of the enterprise to include interrelationships between business units other than the normal hierarchical relationships that the existing “includes” relation allows. This should enable a wider array of analysis models to be created for those architects who need to model a subset of the enterprise.
A page was created on the Wordpress site to discuss the difference between a Process and a Capability. (link)

Of course, we are not done. I am publishing version 3.5 in order to insure that my conversations with other Business Architects has a current footing. The following concerns have been shared and are under consideration for future versions:

Add the ability to attach a Value Chain Analysis
Add the ability to represent the accountabilities of a team in relation to the business processes themselves
<<your suggestion here>>

As always, I welcome feedback and input. I’m proud of where the EBMM has come so far and look forward to working with exceptional people to discuss and describe future changes to the model.

Note: I didn’t keep a careful list of the folks who offered valuable feedback on the model. If you offered feedback, and I didn’t mention you above, please accept my apologies and send me a note. I’ll update this post.

Finding Common Ground: in response to a BPTrends article on Process and Capability

Nick Malik — Wed, 27 Jul 2011 04:03:13 GMT

Recently, Paul Harmon published an article in BPTrends that discusses his views on the notion of Business Capability, and whether it is a useful concept. He was not particularly kind to the field of Business Architecture in his article. While I encourage my readers to take a few minutes to read the original, I have included a few excerpts to give perspective to those with a little less time on their hands:

To date, I have to admit that I have no clear idea of what the term "capability" means.
In other words, as far as I can see, according to this definition, a "capability" is just a way of talking about being able to produce what processes produce.
I don’t see a real difference between WHAT an organization can do and HOW the organization will do it.
I might prefer to call it a Business Process Architecture, but I can certainly live with the term Business Architecture, if that’s what most people come to prefer.
the idea of "capabilities" is introducing confusion into the marketplace. It is hard enough to work with an organization to create a business process architecture that can be used to effectively organize the management and measurement of how well the organization is achieving its goals. To introduce the idea that an organization should first or simultaneously create a map or hierarchy of "capabilities" and then create another hierarchy of processes is to add confusion to an already very difficult and complex task.
If former IT architects want to become business architects, I’m all for it, but they are going to find that there are BPM practitioners who are already functioning in that role, and I believe they will be well advised to work with us rather than trying to create a new body of knowledge with a new vocabulary.
I believe that we ought to resist any urge to quickly redefine terms and practices that we have been using for many years.

My attention was called to this article by a reader of my blog who was interested in my response. This is particularly apropos because, as a member of the OMG Business Architecture Working Group (or BAWG), I am one of the folks that Mr. Harmon is talking about.

First let me say that his criticisms are fair. As any new methodology appears, it runs the risk of creating confusion in the minds of business stakeholders. We are not immune to that criticism. In fact, within my own organization, BPM practitioners have been dismayed by the discussion of business capabilities and have asked many of the same questions that Mr. Harmon asks. In our organization, we have worked to address those concerns and I believe we have been successful. I will be sharing some of those discussions with readers in upcoming posts. In addition, I welcome Mr. Harmon’s questions and would love to work with him, and any other member of the BPM community, to amicably answer these concerns as best I can. I hope that the efforts of the BAWG will produce fruit by providing the consistent basis that Mr. Harmon so clearly calls for.

I don’t agree with Mr. Harmon’s conclusion: business architecture is a ‘redefinition’ of Business Process Management terms and practices. That said, my belief is based on my own practice. I recognize that Mr. Harmon may have been speaking with practitioners who have been using Business Architecture concepts in confusing and inconsistent ways.

Just as business process management did not coalesce as a profession until some key voices published books that entered general business practice, I ask only that Mr. Harmon consider the possibility that Business Architects have not found a small set of clear voices just yet. Our field is younger. Just as the folks who believe that “functional groupings” were a reasonable way to organize a company may have found confusion in the introduction of BPM concepts 20 years ago, I believe that business and BPM professionals are finding confusion in the introduction of BA concepts today. We are not less legitimate as the result of our youth… but we are less coherent.

His confusion is healthy, and through his expression, he provides further demand for the outputs of the BAWG and other BA thinkers who want to resolve his dilemmas and create clarity.

I ask for patience.

I will attempt to answer specific questions in later blog posts. I wanted to start with this message to make it clear that I do not view Mr. Harmon, or any other business professional, as opposed to the ideas that I profess. Rather I view his views as the necessary result of our own poor consistency, in words and practices. I am confident that, as our profession matures and we find our voice, we will demonstrate clearly the ways in which BPM professionals and EA professionals can support each other’s efforts and build a shared model of success.

We can, we should, we must, be united in our shared goal: to improve the ability of our organizations to fulfill their missions.

We want the same things. We are using different tools, at different points in different processes, to achieve them. By working together, and not apart, we will both succeed in a better way. I seek to find that common ground. I beg all who want the same things to help me to find it.

The Rule of EA Governance

Nick Malik — Fri, 22 Jul 2011 00:52:23 GMT

There is a clear distinction between Enterprise Architecture, as described by the architect, and Enterprise Architecture as implemented by the enterprise. I would like to posit the following as a fundamental principle that describes the difference:

All Enterprise Architecture will be implemented according to the structure of ownership and governance that exists in the enterprise.

This is essentially an update to Conway’s Law, but Conway was focusing mostly on application development. Conway’s law, dating from 1968, is:

^“...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. “

Many of the factors that drove Marvin Conway to describe software design are also at play in enterprise architecture. Organizations want to use the teams that they have, so they will design software in such a way that it can be coded by those teams, regardless of whether that is the best way to design or deliver that system. For example, if your company has a team of people who manage the CRM system, and a team that manages Web front-ends, then any business scenario that involves web front-ends on a CRM system will have exactly two modules. One will be written by the Web-front end team and the other by the CRM team.

In Enterprise Architecture, the effect plays out quite differently. EA often creates recommendations to consolidate systems, reduce overlaps, fill gaps, and optimize spending. Since EA doesn’t design software, Conway’s law doesn’t apply.

So how does the Rule of Governance work you ask? If you have two business customers who both want a CRM solution, and you have one governance body, you will end up with one CRM system. If you have two governance bodies, you will end up with two CRM systems. If you have four business units who want CRM, and you have three governance bodies, you will end up with three CRM systems.

This rule plays out repeatedly. I’ve never seen it fail.

The failure to recognize “The Rule of EA Governance” is one of the causes for the failure of an EA program.

Enterprise Architects are an optimistic bunch. We honestly believe that we can influence the course of our businesses (evidence: we work as Enterprise Architects!). We use modeling techniques and engineering principles, and produce nice drawings and great designs. The business doesn’t care about nice drawings and great designs. They care about “stuff they own” and “stuff they don’t own.”

If you want to change the way the business works, especially with respect to shared processes, capabilities or technologies, an EA MUST create a mechanism for the shared “thing” to be owned by only one person. As soon as only one person owns it, and has authority over it, it will exist only once. If two people own it, it is a matter of time before they go their separate ways. Of course, making sure that the RIGHT person owns it, that’s an altogether different problem.

So if you want to know if your Enterprise Architecture can be implemented, count the “things” in it. Then count the number of those things with exactly one owner (and clear governance). Those are the things that will be implemented just the way you describe it. Everything else is a free for all.

What EA Means to One Agency of the Federal Government

Nick Malik — Thu, 21 Jul 2011 22:31:23 GMT

I ran across a document from the Dept. of Commerce that describes Enterprise Architecture as follows:

“An Enterprise Architecture (EA) is a blueprint that explains how the results of Strategic Planning, Performance Planning, Budgeting, Capital Planning and Investment Control, Security and Privacy procedures, Acquisition, and other related information technology (IT) and general management processes work together to meet the enterprise's mission and objectives. The EA development process leads to an integrated framework, based on principles and standards, which explain Commerce’s mission and how resources will be deployed to accomplish that mission. The EA documents the future state of the Department’s information technology based on business and technology drivers as well as the transition plan for moving from the current (as-is) state to the future (to-be) state. An EA modeling toolset helps enable the development and implementation of the EA.” (source link).

Fascinating. Breaking this down a bit, the first sentence of the definition says:

A bunch of processes exist, specifically including but not limited to: Strategic Planning, Performance Planning, Budgeting, Capital Planning and Investment Control, Security and Privacy procedures, and Acquisition.
Other processes exist that are grouped under “related information technology (IT) and general management processes.”
Those process work together to meet the enterprise’s mission and objectives.
An EA is an artifact that provides a blueprint to explain how these processes work together to meet the mission and objectives.

The second sentence says:

An Enterprise Architecture (the artifact) is developed through a process.
Following the EA development process, an enterprise produces an integrated framework.
The integrated framework is based on principles and standards.
The integrated framework explains the mission of the agency.
The integrated framework explains how resources will be deployed to accomplish that mission.

The third sentence says:

An Enterprise Architecture (the artifact) documents the future of agency technology.
The future is based on business drivers and technology drivers.
An Enterprise Architecture (the artifact) documents the transition plan for achieving the future.

The fourth sentence says:

Tools are helpful (but not required) to enable the development of an Enterprise Architecture (the artifact).

There are 13 statements in that definition of EA. Is it really necessary to make 13 statements in order to create a definition of Enterprise Architecture? Apparently the US Department of Commerce thought that it was. There are some interesting statements in there, that represent a particular viewpoint on EA. There are also some statements that may reflect internal politics or discussions.

I am interested in solving a specific problem: how should all EA programs describe themselves? Given that problem, I find the following statements interesting:

An Enterprise Architecture is a thing. It is tangible. It can be delivered, and the act of delivering it can be measured.
An Enterprise Architecture specifically includes IT resources and excludes everything else.
This thing called an EA contains a couple of interesting parts:

An explanation of the agency’s mission and objectives.
An explanation of how the agencies’ resources should, in the future, work together to meet that mission and those objectives.
A transition plan to explain how gaps will be addressed.

I have a couple of big problems with this definition.

The biggest problem I have is the second statement: that an EA is limited to technology. That doesn’t make sense to me. Technology cannot be mapped to the enterprise without a full understanding of the process architecture and shared information requirements of the enterprise. It is good to create a future state technology roadmap after the enterprise architecture is developed, but not before, and not necessarily as part of the enterprise architecture itself.
A smaller problem is that the definition goes into detail by saying that a blueprint will be created, but not much detail on why it is created, how it is created, and when it is supposed to be used. So what is the purpose of defining Enterprise Architecture if you don’t use the opportunity to answer some of these key questions?
Lastly, the definition describes a couple of interesting deliverables, including a blueprint and a transition plan. Why should a select group of experts create them? Can anyone create them? Is there a low bar of quality that we should not fall below? It justifies the creation of the artifact, and even discusses the tools, but not the people who will create it or the skills that they must possess to do so effectively.

What are your thoughts? Is it useful for all organizations to leverage the same definition of Enterprise Architecture? Do you agree with the statements made in this definition? Is an EA a thing? Should the definition of EA mention all of the items mentioned? Should it be extended to fill in the gaps identified?

Putting the brakes on “capability obesity”

Nick Malik — Sat, 16 Jul 2011 03:58:17 GMT

Microsoft IT made a bet, a couple of years ago, on using capability modeling in our own internal Business Architecture program. That required us to have a shared and consistent hierarchy of business capabilities that we would use across all lines of business.

At that time, we adopted principles like MECE (“Mutually exclusive, comprehensive, and exhaustive”) to provide guidance about the contents of the capability hierarchy itself. We set up a process for the team to manage the hierarchy and insure that the principles were followed.

The team did NOT create other hierarchies, and simply “de-scoped” any discussion of a business process hierarchy or a platform feature hierarchy (those artifacts would belong to other teams, you see).

What happened?

The Business Capability Hierarchy (or BCH) grew fat. If we needed a taxonomy element because we were doing platform rationalization, we’d throw it into the BCH. If we needed a list of features so that we could compare vendor products (buy vs. build), we’d throw those in to the BCH as well. The stuff that got thrown in was “worded” as a capability, but it’s hard to know if it wasn’t just a reworded business process or system feature. It’s easy to make things unique. Just add words.

The result is not satisfying. Our current taxonomy is over 2,200 items long. In many places, it is five levels deep. That is really big. Too big. There are more capabilities than there are business systems. More capabilities than there are processes. More capabilities than there are roles. More capabilities than there are business objects. If the point was to be a place where we would consolidate information, we’ve blown that out of the water.

Even if I filter the hierarchy to only show me Level 3 elements, it is still over 650 elements long. Still too big, but if we limit ourselves to level 3, we can put two or three systems under each capability. That’s something. But not enough.

My advice to other companies who are adopting capability modeling: adopt a rich set of “management principles” early on:

Principle	Implication
The Magic Number Seven (plus or minus two)	Level 0 has one item. At each level below, there are exactly seven elements (plus or minus two). If not, re-balance.
Only Level Three Matters	Levels 1 and 2 are for navigation and nothing else. Make associations ONLY to level 3 items. Level 4 is documentation. Level five is not allowed.
No system features	The capability hierarchy must not be used for feature-by-feature product comparisons. Leave features out.
No process variations	If the only difference between two “capabilities” is the process that a person is following when they perform it, merge them. Let the process hierarchy handle that distinction.
Three mappings per application or process	If you map an application or a business process to the capability hierarchy, it will map to three capabilities, at most. If the app or process maps to more capabilities… you have too many capabilities. Merge branches to reduce the hierarchy. (Twist: platform products like SAP should be mapped module-by-module.)
Comprehensive and Exhaustive	Leave nothing out. Don’t just focus on the value chain processes. That will mean that you use valuable “space” to cover supporting processes. This is a good thing.

Net result, your capability hierarchy is unlikely to exceed 300 items. Best if you can keep it under 200. Anything more than that, and even your best architects cannot learn it. It becomes fat. An obese capability hierarchy is not an effective tool for strategic planning. Take my word for it.

Business Strategy and Kindergarten Soccer

Nick Malik — Wed, 13 Jul 2011 15:38:19 GMT

Back when my kids were small, they all played soccer on local youth teams.

It is interesting to watch very young kids play soccer, because the instructions are so simple: kick the ball into the goal. With instructions like that, what do you get? Bumblebees, of course. While many of the kids will wander around the field, or stand in one spot wondering when something will happen, about half of each team will be in constant motion, within about ten feet of the ball. They hover and dive and kick wildly, with the ball hopping in one direction and then another. From the sidelines, all you can see is a cluster of little bodies moving around, and you see the ball kicked first this way, and then that. It’s like watching a cluster of bees gradually move up and down the soccer field.

The behavior of the players is simple. Everyone wants to score. No one wants to pass. No one plays a position because that is too difficult to explain to a five year old. Rules like “offsides” are simply ignored. The kids get dirty and get their exercise. That’s all the parents really want. Most everyone is happy.

So, why bring this up? Because the same thing happens in some companies. There are companies that have honed a senior layer of internally competitive business managers. Each has tremendous ambition to rise to the next level, where prestige is accompanied by a serious bump in pay. This happens in some law firms, ad agencies, and even some large businesses.

Take a company with a highly competitive upper middle management layer, and toss in a business strategy. It’s like tossing a soccer ball into a group of kindergartners. Everyone goes for the ball. No one steps back to take the pass, because no one trusts anyone, and no one is going to be held to their position. There are no real referees. Add referees and the players have to start to mature! The parents (investors) can put in referees, but if they don’t, the game looks like Kindergarten Soccer. Lots of energy. Everyone gets dirty. A few times, someone scores a goal.

It is very difficult to be an Enterprise Architect in a culture like that. No competitive child wants to listen to someone on the sidelines shouting out instructions. Most commonly, an Enterprise Architect can be an advisor, providing pointers to one of the players so that he or she can beat the other players. At best, you can be a coach, but only if the team recognizes that they are a team. Even then there is no “practice time”… only “game time.” No easy way to get these players to practice new skills, develop trust, and take the the field as a team.

Now, you could say that a business strategy should be so detailed, and so well described, that it identifies roles that each person should play. But in Kindergarten Soccer, it won’t work. The kids can’t follow complex plans without their childlike enthusiasm for “kicking the ball” simply taking over.

In some businesses, Business Strategy is Kindergarten Soccer. The only difference: if you are advising a losing player, you can be disposed of fairly quickly. When your kid is out of the game, you go too. Politics trumps Performance every time.

EA Schools of Thought

Nick Malik — Sat, 02 Jul 2011 02:05:00 GMT

As an Enterprise Architect, I’m first and foremost a problem solver. I don’t like to ignore problems. Yet, it appears that EA as a field has a problem and I’m finding it tough to ignore it. What is the problem? If you judge by the 1500+messages that have flooded the Enterprise Architecture Network on LinkedIn, Enterprise Architects cannot agree.

How did I come to that impression? Let’s look at the measures. Across a handful of questions over the course of the past few months, there have been literally hundreds of responses. Judging by the responses, we seem to have, as a group. different opinions about every facet of our profession. We appear to disagree about mission statements, value propositions, metamodels, methodology, inputs, outputs, and the necessary levels of job experience needed to perform.

Certainly the impression is reasonable, but is it a reality.

Yes and No.

There are a handful of “schools of thought” that emerge if you read and discuss. The number of people in each school of thought varies, but there are some clear distinctions between them. The biggest disagreements come from folks who are using the same words, but come from these different schools of thought.

The following list is in alphabetical order. Note that ALL of these folks have presented themselves as Enterprise Architects.

Alignment Architects – these folks are focused on interpreting strategy, making it actionable, and using it to scope and define business change initiatives. Also referred to as Business Architects.
Application Architects – these folks are focused on implementing successful “enterprise applications” or “enterprise systems.” Also referred to as Enterprise IT Architects (EITA)
Information Architects – these folks are focused on managing information assets at the enterprise level in a consistent way
Process Architects – these folks are focused on improving business processes or reorienting business processes to place the customer first.
Strategy Architects – these folks are focused on helping business leaders create new strategies, open new markets, develop new products, etc..

Just to make things interesting, the Zachman framework (ZF) is used by a subset of “alignment” architects as well as a subset of “application” architects. So when you are discussing ZF, you aren’t even sure which perspective they are coming from. It is just as easy to get two “alignment architects to disagree about the value of ZF as anything else.

If you sort out the responses into groups on the basis of these different schools of thought, there is remarkable consistency among the answers. That’s right: consistency. People are saying similar things… sometimes even the same things… about the value, methods, and concepts of Enterprise Architecture.

Perhaps we need to split up the field into specialties, just as physicians have specialties, with some base training and a focus on a particular branch of medicine. After all, an oncologist makes a reasonable diagnosis when you have a cold, as would an Emergency Room doctor, but in the event of a car accident, I’d take the ER doc any day, and in the event of cancer, I’m making a beeline to the oncologist.

If we understand enough about an enterprise, and the problems that they want to solve, we can focus on a single specialty (and/or bring in the right specialist).

Solve these problems	With these architects
We need new products. We need to open up to new markets. New opportunities have arisen. New threats are recognized. New competitive pressures are being felt.	Strategy Architect
We need to be more agile. We need to organize our business to deliver to our stated mission. We need to get our strategies to be realized more quickly. We need to cut waste. We need to focus on what matters. We need to implement new regulations. We need to respond quickly to corporate mandates.	Alignment Architect
We need to implement more scalable technical solutions. We need to integrate and/or replace complex areas of our line-of-business applications with packaged solutions. We need to add process flexibility into our systems. We need to consolidate business rules.	Solution or Application Architect
We need to make our processes more efficient and effective. We need to reduce friction between business groups. We need to minimize the cost of a business process, and remove waste. We need to refocus our processes on customer requirements and customer experience.	Process Architect
We need to create a single version of the truth. We need to reduce the amount of processing needed at each step of an information-based process. We need to reduce the difficulty in producing consistent reporting. We need to manage large amounts of information. We need to improve the ability of business units to communicate through consistent information.	Information Architect

Perhaps if we begin to see that these folks are EACH needed, at different times, to solve different problems, we can spend much more time agreeing with one another.

Video Podcast: How Microsoft Does Enterprise Architecture

Nick Malik — Thu, 23 Jun 2011 17:36:23 GMT

It is amazing how often I need to share the very basic concept of Enterprise Architecture with my peers, customers, stakeholders, and associates. Microsoft’s customers often ask about Enterprise Architecture, and when our customers come to visit us in the Microsoft Executive Briefing Center, they are more frequently bringing their Enterprise Architects along for the conversation. To help clarify our view of EA, I teamed up with the Microsoft Showcase team and Microsoft Studios to produce a podcast describing Enterprise Architecture.

The podcast is located on the Microsoft IT Showcase site here.

I thought about including a transcript, but I don’t have one. I mostly spoke from an outline. If you have questions or comments on the video, please don’t hesitate to contact me and we can collaborate.

Technorati Tags: enterprise Architecture,business architecture,it governance

IT is part of the business, but not for the reasons you think

Nick Malik — Thu, 16 Jun 2011 10:52:00 GMT

A colleague of mine, Gabriel Morgan, pointed out a recent Infoworld article by Bob Lewis called “Why running IT as a business is a train wreck waiting to happen.” So, I read the article and while I agree with some of Mr. Lewis sentiments, his logical arguments are completely random and his conclusions are therefore without basis. His article is one giant non-sequitur.

In the article, Mr. Lewis points out that many IT groups have adopted the mantra of “running IT like a business.” He goes on to indicate that this is a bad idea and quotes a few folks in interesting ways. The logic of the argument starts to get really weird from there, completely failing to make connections.

Let’s take a moment to examine the logical argument that he made and see if it holds up.

Assertion: Running IT like a business is nonsense.
Evidence: CIO complaint that IT cannot deliver competitive services: e.g. a $200 PC to a business customer (won’t run his apps), or cheap file and print server hosting.
He then goes on to discuss situations where the IT department listened carefully to the customers and created bad solutions that met their needs exactly as described.

Somewhere along the way, Mr. Lewis has implied something… that these two things are somehow related to one another. He has assumed that “running IT like a business” is the same as “doing everything your customer asked, even if it is crazy.”

The kernel of the argument finally comes about half-way through. Mr. Lewis states:

“When IT acts as a separate, stand-alone business, the rest of the enterprise will treat it as a vendor. Other than in dysfunctional, highly political environments, business executives don't trust vendors to the extent they trust each other.”

Mr. Lewis is not ambiguous in this statement. If you run IT as a business, he says, you kill trust. Why? Because no one trusts a business. They must be in it for themselves. They must not be on my side. Businesses are not to be trusted. From a logical standpoint, A implies B. Period.

Unfortunately for Mr. Lewis, it is fairly easy to disprove an implication like that… find a single case where A doesn’t imply B. One single case is all we need. With one case, the rule is broken… the argument becomes a fallacy. That doesn’t mean that the conclusion is wrong. It just means that the conclusion is not supported by the argument. The conclusion could be correct, but not caused by the things he says are the cause.

And this is why I had such a hard time reading this seriously flawed article. I saw that the argument was a fallacy because I was able to disprove it almost instantly. And I bet you can too.

Thought experiment:

Is there a business that you trust? Any business? Let’s say that you took a loan to buy your car. You pay a fixed amount of money every month to pay off the loan. You are doing business with that bank.

Do you trust the bank? Technically, they could come and repossess your car at any time. Yet, I’m willing to bet that most of my readers have gone all the way through a car loan without ever being in fear of repossession. Why? Because you TRUSTED the bank… as long as you paid your monthly payment on time, you TRUSTED that it was in their best interest not to repossess the car.

Here’s another case.

Does your company use a payroll processing vendor to handle the payroll? Many companies do. After your company started using the payroll processing company, did a bad relationship result between your company and the payroll processing vendor? I’m sure that happens sometimes, but given the fact that most companies are extremely loyal to their payroll processing vendor, it doesn’t happen that often. The payroll processing vendor offers a clear and simple service. The business buys it. Everyone is happy.

Mr. Lewis goes on to dispense GOOD advice, but he does it in the name of getting rid of the BAD mantra of “running IT as a business.” The good advice is good, despite the fact that it had nothing to do with the BAD things he pointed at.

For example the article states:

Nobody in IT should ever say, "You're my customer and my job is to make sure you're satisfied," or ask, "What do you want me to do?"

Instead, they should say, "My job is to help you and the company succeed," followed by "Show me how you do things now," and "Let's figure out a better way of getting this done."

This is good advice.

But the bad practice of “doing whatever a customer asks” is NOT the result of “running IT as a business.” I don’t know of many businesses who run that way. Let’s see if you do. Thought experiment: Please provide an example of a business that you do business with today in your personal life that meets this criteria: you hire them to provide you a custom service. You tell them how to provide the service, what the service will look like, all the features and aspects of the service, and then you ask them to operate the service indefinitely while you complain about the cost.

Go ahead. Name a single business in your personal life that runs that way.

What really happens? Let’s see. You go to a car dealership and you say “I want a car.” The dealer asks some questions and then points you to one of their STANDARD services (one of their five car models) and then tells you how that model will meet your needs. They don’t offer a car with five wheels or three engines. They have a set of products and they help you to pick the best one.

Let’s consider another business, a service business. I pay my cell phone bill every month. Sometimes it costs more than others. If I look at my bill, I may see that I downloaded ringtones, or went over my allotted number of minutes. The service is custom: after all, I got different services than my neighbor, right? Not really. I got different Quantities of the same services. The services were standard. What varied were the quantities.

Here’s another example: go into a restaurant. Buy dinner. When the bill comes, ask the restaurant to break down the costs of the bill. Let’s say I take my wife to a nice steakhouse. We spend $100 on a nice dinner. When the waiter brings me the bill, can I send it back and ask the business to tell me where every dollar went? Can I decide not to pay for the bathroom (after all, I didn’t use it)? How about the fees that the restaurant pays for health inspections? Can I choose not to pay for that? No… because I got $100 worth of value from my experience.

That is what it means to “run IT as a business.” It means to make sure that the business gets value out of their experience.

In Microsoft, we have more than one IT group. We have several. I watched an excellent example play out that I’d like to share… one which shows the value of “running IT as a business.”

In three separate IT groups, we were doing eCommerce in different ways. One group (team R) had a single storefront, and they did their billing through an agreement with Cybersource. In another group, (Team O), there was a nice platform for building eCommerce sites that was used by about 20 different areas of the business. You could build a front end, shopping basket, and checkout process for a flat price and the team took care of all the backoffice stuff for you. Your business got all of the revenue minus the service charges that the bank charged. In a third group, (team C) an independent business unit had created their own eCommerce system that did only the credit card billing but none of the front-end work. This one charged its customers on a per-transaction basis.

Over the years, these different teams would compete with one another. Every time a new business need arose for eCommerce, that business could visit each of these three different groups to ask what they did. Most folks don’t want to create an eCommerce platform so there is a built-in incentive to reuse things.

All this played out over nearly a decade. Nowadays, one team has become the clear winner. Nearly all eCommerce in the company goes through it. The other two still exist, but not for long. Both are on the way out.

Did the survivor have the best platform? Nope. It was not the most reliable. It was not the one that handled the most currencies, or ran in the most countries. It was not the easiest one to build to. So why did it succeed?

I believe it was because that IT team had a very simple model for offering themselves as a service to their business customers.

Basically, any business in the company could use that particular platform for a transaction fee. But it wasn’t an accounting nightmare. There are no bean counters. No complex charge-back schemes. It is much simpler than that.

Each business unit answers two simple questions at the beginning of the budget cycle: (a) which of the three standard eCommerce services do you want to buy, and (b) how many transactions do you estimate you will incur? That’s it. With these two variables and a little simple math, each team would PREPAY for all of their eCommerce services for the year. Easy to budget. All the “rules” fit on a single page. Nothing complex. Estimates were based on last year’s numbers, so it was pretty tough to “intentionally underestimate” the transactions. All the differences ended up simply washing out.

But what if you are a business customer of the eCommerce service and you want some changes? You want the eCommerce team to add a feature? Go ahead and ask. It’s a software project, and you will still pay for the changes, but the interesting thing is this: the changes ended up being subsidized. You see, the program made a small profit on the sale of per-transaction fees. They used that profit to subsidize the change requests, so that each change request ended up costing far less than a typical IT organization would charge.

It is easy to compete when you do a little creative cost-shifting. That is how businesses actually run: Standard services at Reasonable prices. Solid value that is clearly articulated. Understandable billing. Good customer service. Oodles of cost shifting.

Successful businesses run that way. Apparently, so do successful IT services.

The per-transaction fees were easy to understand and, like the $100 dinner, were not cheap but were worth the cost. More importantly, that IT team did not divulge every detail of the costs to their business customers. There was no need to account for the cost of architecture and the cost of project management and the cost of hardware as separate line items. The customer never saw any of that. Customers saw the cost of something they could perceive as valuable: the cost of the transaction. Everything else was hidden. Just like I may pay for the steak dinner, and the restaurant would pay for the cook and the electric bill, the customer of the eCommerce service paid for the transaction and the IT team would use that money to pay for the architect and the ESB bus.

That is what it means to “Run IT as a Business.”

All I need is one case to disprove the logical argument that Bob Lewis presented in his InfoWorld article, and I had found it… many times over. Mr. Lewis’ argument is flawed because Mr. Lewis seems to ignore the way businesses actually run.

On the Hunt for the One-Page View of an Enterprise

Nick Malik — Fri, 03 Jun 2011 17:55:52 GMT

I am currently noodling the idea of a one-page view of my employer (Microsoft) for the purpose of rationalizing the sharing of services across business units and business models. (If you understood the previous sentence, you are probably an enterprise architect, even if that is Not your title).

As a result, I’m on a hunt for the various one-page views that other companies have produced. The excellent book “Enterprise Architecture As Strategy” (Ross and Weill) provides three tangible examples (Delta Airlines, ING-Direct, and MetLife). A fourth I found entirely by accident this morning… a very old one drawn by a Disney cartoonist in 1957, and made available here: (http://taotwit.posterous.com/the-visualisation-of-business-models-did-disn).

This is an interesting view in that it illustrates the relationships between the business units and how they functionally support one another. It doesn’t allocate responsibility, but rather demonstrates responsibilities through the relationships. In effect, it is a somewhat “contractual” view, indicating the accountabilities between business units. Fascinating for many things, one of which is the date.

The synchronicity of this find is resonating for me because yesterday, a friend and fellow Enterprise Architect within Microsoft named Krishna Srinivasan, shared a very similar view that demonstrated how the functional units of Microsoft could be viewed. I’m sharing it here because, honestly, the view was so generic that it is difficult to view it as “revealing” anything that someone couldn’t guess. That said, it is a fascinating, modern depiction of many of the same key concerns that the 1957 view of The Disney Company was trying to illustrate. One key distinction: in stead of communicating relationships in terms of accountabilities, it demonstrates process relationships (inputs and outputs).

One bit of brilliance to consider is that you can track the various processes in the company by following the arrows from box to box to box. It doesn’t quite meet the needs I’m looking for in shared service rationalization, but it does say a lot about how organizations can be represented visually.

Has the concept of “alignment” entered the infamous “trough of disillusionment?”

Nick Malik — Tue, 31 May 2011 10:33:42 GMT

In the May 15th issue of CIO magazine, there is a rather interesting article, especially for Enterprise Architecture practitioners. The article, written by Stephanie Overby (a freelance writer), is titled “RIP I.T. Value” and opens with the following paragraph:

The end of IT-business alignment is nigh. And no one is happier about it than the business focused CIO.

“If you stand in front of an audience of CIOs and start talking about IT-business alignment, at best you get eye-rolls and at worst, you get people walking out of the room” says Shawn Banerji, a New York based CIO recruiter with Russell Reynolds Associates. “Alignment has been a big trend for quite some time and—as with most trends—it has gotten a lot of lip service. But the ability to move beyond that into the practical manifestation of IT and the business being one is a progressive reality for a lot of organizations today.”

Reading down through the article, I’d like to include some interesting excerpts:

Excerpt 1:

According to Gartner, by 2015, the primary factor determining incentive compensation for the CIO will be the amount of new revenue generated from IT initiatives.

Excerpt 2:

CIOs used to measure their personal value by budget or headcount and their team’s value by delivering on time and on budget. “That’s an arcane approach to measure your relevance,” Banerji says. “Historically, they’ve talked about alignment because that’s all they could possibly hope for.” Today, CIOs are more likely to be rewarded for overall business performance than for some technology project or initiative, Banerji says.

Excerpt 3:

CIOs further along in their efforts to measure business impact are putting IT-centric measures like uptime and systems availability on the back burner to focus on business goals like customer retention and operating efficiency.

To be fair to the author, the article cites some fairly well-versed individuals. In addition to the recruiter (Banerji), it also references current CIOs (Louie Ehrlich, CIO of Chevron, and Brian Hardee, CIO of Oxford Industries), a Gartner VP (Dave Aron), and a well-placed attorney (Edward Hansen, partner, Baker and McKenzie). I do not fault the author. However, I wonder if we are throwing the baby out with the bathwater.

In most businesses, IT is not a front-office endeavor. Clearly, deep information integration is blurring that line, but only partly. If IT moves to be revenue focused, I am concerned that IT can lose sight of 80% of its’ value: keeping the lights on for the parts of the business that traditionally make money.

Now, also to be fair, the quotes from the cited CIOs reflect a focus on changing the measurement structure, not ignoring existing business. To whit, one very interesting example at Chevron where the old “99.9% uptime” metric has been augmented with a “business incident index” that tracks the number of IT service issues that affected business and the impact of each in terms of revenue and reputation. This is healthy, and I applaud this kind of metric. I’m simply concerned that we keep focus on many of the existing metrics as well, and not change CIO compensation to focus on new revenue to their exclusion.

Interesting, also, is the fact that the author never mentions Enterprise Architecture. Clearly, we need to be reaching out much further than we are.

What do you have to say, fellow architects? Is the trend towards “IT as business value provider” healthy? Are there risks here? What should we do to mitigate them? What is the opinion of the EA community in this development?

Metamodel 101

Nick Malik — Fri, 27 May 2011 00:42:17 GMT

I was just privy to a conversation about the value of creating a specific kind of metamodel, and it made me wonder… if I had to explain the concept of a metamodel to someone, how would I do it?

First, let’s start by defining the term “metamodel.” The IEEE Online Software Engineering Vocabulary (SEVOCAB) provides 12 different definitions for the term ‘metamodel’. In my opinion, the definition most applicable to enterprise architecture is this one:

CDIF semantic metamodel. (1) the description of the set of concepts and notations used to define a model (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2) Note: The CDIF semantic metamodel defines an Entity-Relationship-Attribute model that is used to construct and define models used in systems development.

Peel away the jargon, and you get this: a metamodel defines the stuff that you put into your models.

For example, I created this model of a fictitious company, Contoso. They have created some strategies, and the Enterprise Architect has tied those strategies to business initiatives and those business initiatives to the business units that are impacted by those initiatives. (A simple traceability model).

If the diagram above is a model, what is in the metamodel? That’s the diagram below:

In this metamodel, we provide definitions for three terms: strategy, initiative, and business unit. They are meaningful in the context of the model and should have a single definition. In addition, the metamodel defines every relationship that is allowed between these elements. We can say that an initiative may involve a business unit, but our model cannot show the relationship of a business unit to a strategy UNLESS there is an initiative that is aligned to that strategy and which involves the business unit.

A metamodel restricts what you can draw. It prevents you from drawing things that don’t make sense. And it clearly defines the terms so that when someone reads your model, they know WHY you described some things as strategies and other things as initiatives (for example).

A metamodel is the grammar and definitions of words. It provides the dictionary. The model itself is the story you tell with those words.

Tutorial over for the day!