Inside Architecture

Setting Up A New EA or BA Practice

Nick Malik — Sun, 20 May 2012 19:49:57 GMT

Recently, I was contacted via this blog by an individual who had been challenged to set up a new Business Architecture practice within his company’s Enterprise Architecture team. He reached out to me to ask about some books to read and some advice. I’m expanding my message to him here. As always, I’d love to hear your comments and feedback.

-----

You have quite a challenge ahead of you. While it may seem obvious, there are some steps that you need to do first. You have to essentially manage the change that you are bringing to your own organization.

Value Proposition: Get together with your sponsor and create your charter. This is critical to having a clear goal that you will achieve, and clear measures by which you will achieve them. I cannot underestimate the importance of this step. Do not skip.
Engagement Model: Create a clear and simple process for deciding what your team will focus on and how you will find the right opportunities to attack. This is your engagement model. Formalize it, and stick to it. You will be pulled in every direction. Clear simple criteria is your only defense against being scattered to the wind.
Clearly define your service: what deliverables will be produced, and which individual stakeholders are going to be expected to use those deliverables, at what time, to what end.
Stakeholder buy-in: With the help of your sponsor, meet one on one with each of these key stakeholders and make sure that they understand your value proposition, resources, and process impacts. You may be changing the lives of some key people. Get their buy-in.
Scorecard: Hold yourselves accountable. Create a scorecard and use it with your team to demonstrate how progress should occur, and use it with your leaders to show how value has been delivered.
Staff Training: Send everyone to a training class in Business Architecture… not so that they are all educated, but so that everyone is educated on the same terms, artifacts, and processes. This is the most difficult one to offer advice on because I have not yet found many good options… then again, we have an internal team that has answered the call, so I have not lately looked. Perhaps good options exist.

As far as required reading… specific to the BA practice challenge

The list below is intentionally short. I feel that every member of the team should read each of these books. I placed them in order of usefulness for your task at hand (preparing the staff of a new BA function within an EA team). All are very valuable… but being higher on the list means that I consider the book to be more valuable, sooner, than the ones below.

“Business Architecture: The Art and Practice of Business Transformation” by Neil McWhorter and William Ulrich
“Crossing the Chasm” by Geoffrey Moore
“How to Measure Anything” by Douglas Hubbard
“Enterprise Architecture as Strategy” Jeanne Ross and Peter Weill
“Competitive Advantage” and “Competitive Strategy” by Michael Porter
“Make It Stick” and “Switch” by Chip and Dan Heath

For the team manager, one more book to be read concurrently with the ones above:

"Business Architecture: An Emerging Profession." Paul A. Bodine and Jack Hilty

------------------

OK… I have probably just angered some of my friends, because I didn’t include all of their books or reference materials in my short list. Please, before you flame me, realize that this response is to a specific individual with a specific problem. The EA team existed, but didn’t have a BA function… what does that tell you? That it is an EITA team, in all likelihood. Is every possible book or resource appropriate for that situation? Probably not. So I selected a small set of valuable books. There are many more out there.

EA Certifications Distilled

Nick Malik — Tue, 08 May 2012 15:24:32 GMT

Mike Walker, one of my colleagues here at Microsoft, has done an excellent job of distilling various options for EA certification. He made this presentation at the most recent Open Group Conference. Strong Recommend.

Enterprise Architecture Certifications Distilled

View more PowerPoint from Mike Walker

On the road to a Business Architecture Manifesto

Nick Malik — Sun, 06 May 2012 20:59:07 GMT

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

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

First off, in order to develop principles for business architecture, we need to describe the problem that we are trying to solve.

The problem that business architecture solves

Business architecture is a relatively new field that addresses an old problem. Most business people recognize the underlying truth: the structure and practices of your organization directly impacts your ability to deliver the intended value. Whether we are talking about a military service, a civilian government agency, a non-profit organization, or a for-profit business, the structures and processes that a leader chooses to employ will impact the results that the organization will produce. That includes both intended and unintended results. So the basic problem is this: how do we deliver on our mission while maintaining our values?

Business architecture gets to deal with a slice of that problem. As people, we need to organize around a common shared mission. We need to know what we want, and we need to go get it. Humans can be pretty haphazard. Business architecture does not address every issue. Business architecture attempts to answer this question: what is the optimal way to organize? Business architecture typically does NOT answer questions around the integration of corporate controls, or supporting activities like how to find staff to fill new roles. Business architecture is focused on the narrow slice of “how to organize.”

So why do we need business architecture to solve this problem? There are literally hundreds of good, well researched, books that offer useful insight for solving this problem. Why use a business architecture approach? Because BA brings a novel approach, one based on the rigorous application of conceptual traceability, process improvement, information science, and mathematics. While most of the business analysis methods prior to business architecture were founded, fundamentally, in social science, mechanical engineering, and even education, business architecture focuses on the newer sciences that have emerged in the computerized age.

How does business architecture solve the problem

Business architecture’s unique value proposition is to focus on answering the questions of business structural and organizational effectiveness in a way that is rigorous, quick, clear, consumable, and value-focused.

We are uncovering better ways of developing business insight by doing it and helping others do it. Through this work, we have come to value:

Consistently reusable methods over Piecemeal assortment of best practices

Rapid insight over Deeply accurate models

Clear choices over Nuanced decision trees

Consumable deliverables over Consistency with external frameworks

Value-driven prioritization over Justification of the status quo

That is, while there is value in the items on the right, we value the items on the left more.

To break that down:

Repeatability, Reuse, and Rigor. There are many ways to understand a business. Business architects will expect you to pick one of those ways (one conceptual model) and then stick to it. The rigor comes from sticking to the model. If your enterprise is focused on creating a smooth customer experience, then the business architect will leverage the customer experience work done elsewhere, and will drive a business stakeholder to follow along rather than make something up. While products must be creatively and freely developed, the organization itself must be architected and engineered. Rigor matters.
Rapid Insight. There are many ways to analyze a business. Business architects will work to reduce the overhead of their analysis methods so that they can produce valuable answers in a very timely manner. Business people are not rewarded for taking a long time to do an excellent job. Most will be better rewarded if they do a reasonably good job in a shorter timeframe. While accuracy is great, the value of information is inversely proportional to the time needed to produce it. Speed matters.
Clear Choices. If a business person cannot tell what the recommendation is, they won’t follow it. If the business architect cannot produce insight that is clear for the business stakeholder, the architect will not effect change. It is not good enough for a business architect to be quick and correct… they must also be clear.
The amount of information, and the coarseness of the decisions, depends on the level of the stakeholder. At any level, a decision maker should be provided a short list of options (often 2 or 3) where the distinctions between them are clear. This rule applies at all levels of the organization. One strategy from a senior manager may require a choice among three different tactics for a department head to choose from. No one person needs to be concerned with the entire decision tree, except perhaps the business architect himself. The ability to make decisions is proportional to the clarity of the choices. Business architecture favors clarity over nuance.
Consumable Deliverables. In order for business architects to be successful, they must deliver a plan for the execution of business strategy. That plan has to be something that the impacted stakeholders can understand and use. In other words, the output of business architecture must be consumable. Reams of technical detail are rarely useful. At the other end of the spectrum, vague goals and promises of value may be just as inappropriate. Recommendations must be provided using words and metaphors that the actual impacted business stakeholders understand. They must be provided using forms and templates that the existing organization will recognize and can quickly use. While consistency with frameworks and practices are important, business architects value consumability more.
Priority based on Business Value. Business architects can spend their time on many tasks. In addition, they can recommend that the organization spend time on many tasks. Sometimes, even an efficient use of business architecture would be a waste of time if the resulting advice is unlikely to deliver strategic insight. The selection of tasks, which to do now and which to do later, is of critical importance to a business architect. While all supporting tasks can be justified, business architects will give priority to tasks that directly lead to actionable, consumable, value-driven business advice.

I’m always looking for insight and feedback from the community, so please feel free to add your comments.

Please note: if your comment is long, the software will sometimes have trouble. Write it in notepad or Word first, and then cut and paste into the comment edit window. Don’t be afraid to send it more than once. I will delete duplicates. If all else fails, e-mail your comment to me and I’ll put it in.

Should We Kill The Architecture Review Board?

Nick Malik — Wed, 18 Apr 2012 05:06:25 GMT

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

CobiT recommends an ARB? Really?

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

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

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

But what is wrong with an ARB?

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

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

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

So what should we do instead of an ARB?

The replacement: The IT Governance Board

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

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

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

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

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

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

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

Podcasts with the Canadian Information Processing Society

Nick Malik — Fri, 13 Apr 2012 18:53:57 GMT

I was honored, recently, when the Canadian Information Processing Society (CIPS) decided to interview me on the topics of Enterprise Architecture. The first of those interviews has appeared on the CIPS.CA web site. You can link to it from here.

http://www.cips.ca/CIPS-INTERVIEWS-Nick-Malik-April2012

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

Nick Malik — Sun, 08 Apr 2012 23:05:51 GMT

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

Graves’ trilogy: Analyst-Anarchist-Architect

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

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

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

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

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

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

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

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

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

Different Efforts, Different Results

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

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

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

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

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

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

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

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

Business Analyst and Business Architect as one person

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

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

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

Business Analyst and Business Architect as complementary roles

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

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

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

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

Conclusion

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

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

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

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

The difference between business architect and business analyst

Nick Malik — Fri, 06 Apr 2012 19:18:47 GMT

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

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

Definitions

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

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

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

Comparison

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

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

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

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

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

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

To whit, the BABOK v2 specifically states:

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

That is a very expansive definition.

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

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

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

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

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

Technorati Tags: business architecture,enterprise architecture,business analyst,information technology

Time-to-Release – the missing System Quality Attribute

Nick Malik — Fri, 09 Mar 2012 09:26:25 GMT

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

Different lists of criteria

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

So where do we get these lists of attributes?

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

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

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

The missing criteria

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

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

How is that quality?

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

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

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

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

So your priority may be, in this example:

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

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

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

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

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

How Enterprise Architects can cope with Opportunistic Failure

Nick Malik — Mon, 05 Mar 2012 20:53:50 GMT

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

What is Opportunistic Failure?

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

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

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

The scenario works like this:

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

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

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

Thoughts on Opportunistic Failure

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

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

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

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

Conclusion

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

MSBI–Part 2—What is a core diagram?

Nick Malik — Tue, 14 Feb 2012 15:40:00 GMT

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

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

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

What is a core diagram?

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

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

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

The value of a core diagram

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

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

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

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

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

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

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

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

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

What are the criteria for a core diagram

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

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

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

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

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

Technorati Tags: Enterprise Architecture,Strategy,Core Diagram

Creating a Core Diagram for Agile Business

Nick Malik — Wed, 01 Feb 2012 00:47:00 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 value does it provide?
Who cares about a core diagram and what are the scenarios for use? What should be represented?
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.