Nick Malik

Conversational Antipatterns on Message Boards

by

Architects argue.  I have, over the past year, spent a good bit of time on LinkedIn Message boards.  I’ve watched a lot of people argue.  I’ve learned a great deal about Enterprise Architecture, and a few things about myself, as I’ve compared notes with individuals who have different perspectives and motivations. 

That said, some patterns have emerged, good and bad, for conversing with other architects on these message boards.  In the spirit of the GOF Design Patterns, and the subsequent work on Antipatterns, I’d like to point out some of the antipatterns I’ve noticed repeatedly on the boards, and in each case, these antipatterns cause some level of anxiety.  This is borne out by observing the responses, where frustration is often explicit.

There are nearly always two roles in this kind of argument.  The provocateur ( a person who makes a statement that is challenging or innovative ) and the responder ( a person who responds in a way that triggers the antipattern behavior ).  

Conversational Antipatterns

  1. Don’t misrepresent me with my own words
  2. The problem with your general message is this specific use of a word
  3. If you don’t understand, you should read my published papers
  4. My argument has been validated with my years of experience, so you must be wrong
  5. My certification means more than you think it means
  6. You are using “my” terminology wrong

 

Antipattern 1: Don’t misrepresent me with my own words

In this antipattern, the provocateur will make a statement that appears to conflict with something that they said previously or said in another discussion.  If the responder points out the conflict, especially if done with a direct quote, the provocateur get’s offended and becomes defensive.  Conversation ends.

How to avoid: People are inconsistent but believe that they are quite consistent.  If a provocateur appears to be inconsistent, the responder should simply ask for follow up details.  Don’t pounce in public.  Find out what their real underlying thinking is, rather than picking at words.  If they remain inconsistent, the responder should reach out in private.  In the private message, the responder should point out the text from the other thread and ASK them to explain how these two positions work together. 

How to address: The forum moderator should look at the value of the conversation.  Has the provocateur added useful thinking?  Has the responder?  Normally, the answer to both questions is “yes.” If so, send a warning message to both asking them to assume positive intent and consider the emotional context of the other.

Antipattern 2: The problem with your general message is this specific use of a word

In this antipattern, the provocateur will make a general statement designed to express a “grand idea.”  The  responder will either agree or disagree (usually the latter) but then point out that a particular word, in the response, was used incorrectly.  Perhaps they said “process” when they should have said “capability.”  Perhaps they said “activity” when they should have said “process, activity, and practice.”  Perhaps they said “business” when they should have said “enterprise.”

How to avoid: The responder should start by stating whether they agree with the main idea, or not.  If they disagree with the main idea, offer a reason “why” that has NOTHING to do with the detailed wording.  Take the time to think about what the big idea is, and follow up to understand it, before focusing on a word.  Disregarding a “big idea” because you disagree with a minor distinction in the wording is frustrating to everyone on the community, and stifles the sharing of ideas. 

When you get to the point where you understand the big idea, the responder can offer a suggestion to improve the understanding the idea.  For example, “I agree with your core concept.  It appears that we have similar experiences and I find your description innovative.  It may help, as you go forward to share this idea, if you are careful about the use of the word “zyzzix” because I understand that word to be a synonym of “fryzzam.”  I understand that you make a distinction between these terms, but not all of your audience may agree that these two terms are distinct.  You may find it easier to reach people like me if you use the term “golozarat” instead to refer to this muddy concept.”

How to address: Either of the participants can pull back and “get to the point” by reframing the “grand idea” and ask if the other person agrees with a simple “yes” or “no” answer.  If no answer is forthcoming, no learning is happening.  If you are asked to consider a new big idea, take some time before you respond to think about that idea.  Be willing to learn and grow, not just pontificate.  My father used to say, “sometimes, the best way to open your mind is to close your mouth.”  It’s good advice.

Antipattern 3: If you don’t understand, you should read my published papers

In this antipattern, the provocateur will make a specific statement that appears well thought out, but may be innovative or controversial.  When the responder asks questions for follow-up, the provocateur replies “I explained this in rich detail in my book” or “please read my paper in the Journal of EA Innovation, September 2005, page 14.”  This generates frustration on the part of the readers who cannot hear the full discussion because some of it exists in a book or article that they may not have access to.

How to avoid: First off, if you are an author, you must realize that publishing a paper or book does not give you the right to force others to read it before speaking with you.  You will never be out of the “business” of educating others in your ideas.  Get used to it.  Getting defensive is counterproductive.

To avoid creating frustration, it is OK to point others to your work, but then ALSO offer a summary of what you said in that work and be willing to continue to discuss the problem in the forum.

How to address: When this happens to you, it is probably safe to assume that the author you are speaking with is looking for some validation.  Compliment him or her, and ask them to provide a summary of their thoughts from the book or article so that progress can continue.  If you are a moderator, and one provocateur does this a lot, or gets defensive when others DON’T read their articles, remind them privately of this antipattern.  If they persist, suspend them from the board for 30 days.

Antipattern 4: My argument has been validated with my years of experience, so you must be wrong

In this antipattern, the provocateur will make a statement that appears to be too directive or too specific for others to understand or agree with. If the responder challenges the position, the provocateur claims that their “years of experience” have found their position to be true.  The provocateur remains unbending, and repeatedly argues against any alternatives.

How to avoid: This is tough to avoid.  People form their own mental models of reality and when challenged, they can listen to alternatives, or defend their model.  The problem with listening to alternatives is that it is risky.  They may discover that a past “success” was not as successful as it may have been.  In the words of my friend Jack, “their ears are filled with their ego.”

Often the best way to avoid the problem is to model good behavior in your own contributions.  When posting an opinion, lead with “in my opinion” or “in my experience.”  Use phrases like “I’ve found this to be true in my situation,” and then ask others to share “their situation.”  That way, when someone does respond with a statement like “you are wrong,” you can follow up with a moderation message, like “I believe that our experiences may be different in this respect. I’m glad that you shared your experience.  Can you tell me how we should reconcile our two different sets of experiences to come to a mutual understanding?”

How to address: Usually the best way around this is to respond as above, asking for a common understanding.  However, if that doesn’t work (and it often will fail), then you have no leverage to “require” someone to change their opinion.  Ask if it is OK for the two of you to “agree to disagree” and move on.  There is no point in discussing the same issue over and over.

Antipattern 5: My certification means more than you think it means

In this antipattern, the provocateur will state that a concept that he or she is fond of, applies to the discussion at hand.  When the responder questions the concept, the provocateur responds that they are “certified” or otherwise demonstrably educated, and their certification tells them to use that concept.  Upon inspection, it is clear to all that the certification in question does not cover the same scope as the provocateur claims it does.  An example would be an IT person, certified in the development of software interfaces called “SOA Services,” claiming an understanding of business services or customer services.  Another example would be a person with substantial training in financial risk management claiming that all business decisions in the enterprise begin, and end, from a risk management viewpoint.

How to avoid: As with most of these antipatterns, we have a situation where the ego of one or more of the people may be getting in the way of open communication.  The “certified” individual may, in fact, have broader experience than their certification prepares them for.  However, there is often a predisposition, among those that have been formally trained in a field, to believe that the training describes the world “as it is” rather than the world “as it should be.”  More often than not, the training is simply out of sync with the reality on the ground.

As a result, of the “ego factor,” this antipattern is somewhat inevitable.  It will occur more in some areas than in others.  Unfortunately, in the EA field, it occurs often because of the explosion of certifications and the lack of consistency among the field participants.

How to address: One good way that I’ve found to address this problem is to point out your own experiences, using words that reflect that you are not dictating some universal truth but rather the experiences you’ve actually had.  Use first names of people (replace the actual first names, to protect your friends), and explain how they used the terms and concepts of the space.  Then describe how you worked in that situation.  Try to use successful scenarios to lend credibility to your position.  You want to help them to see that their position may not be universally true.  You don’t want to prove them to be wrong, because that would simply be your ego trying to stomp on theirs.  There are names for this kind of ego-vs-ego behavior.  Avoid it.  It hurts your credibility to engage in it.

Antipattern 6: You are using “my” terminology wrong

In this antipattern, the provocateur will state that a concept has one, and only one, meaning.  The responder suggests an alternate meaning, and the provocateur responds defensively, citing sources for their definition of the term.  This is where you see a “dictionary grudge match” where someone cites a definition from an authoritative source, and another person responds with either ridicule of the source or, even better, another authoritative source with a conflicting definition.

How to avoid: Firstly, if someone questions your use of a word, don’t immediately go hunting for a reference definition.  In other words, model good behavior.  Admit that your definition, regardless of how well sourced it is, was created by other (fallible) people with a particular context in mind. It is entirely possible that the provocateur also has a different context than you, and that the author of the definition that you are painstakingly citing would have created a different definition if he or she had the same context as the provocateur.

Of course, if someone asks you for a reference, it is perfectly appropriate to give one on a message board.  In writing a research paper, you would assume that the reader wants to know your sources, and you would always provide them, but for conversation on a message board, you should wait to be asked.

Secondly, don’t be “possessive” about the terms that you use.  Your openness will reduce the likelihood that others will be possessive about the terms that they use.  If someone wants to use a synonym, agree. 

How to address: One good way that I’ve found to address this problem is to ask the provocateur for their help in explaining their terminology to you.  Most people will be flattered by the request, and will go out of their way to describe what their use of a term means.  If you respond by “reframing” their statement, using a smattering of your own terminology, then you will quickly discover whether that person is interested in conversing with a shared set of terms, or if the conversation can only proceed by acquiescing to their use of language.  If the latter, it becomes a judgment call, on your part, about whether you should continue to interact at all.  It is better to end a discussion on a good note than to fight on forever over the meanings of words.

—-

That’s my list.  I’m sure that there may be more, but these are the ones that crop up often enough for me to want to write about them.  I hope this is helpful for folks who want to discuss things on message boards, like LinkedIn, without becoming entwined in endless arguments.

On My Move To Consulting Services

by

This is the official announcement.  After seven years of providing Enterprise Architecture services to my own company, Microsoft, I’ve decided to move into the Microsoft Consulting Services division and offer my Enterprise Architecture skills and experiences to other companies through Microsoft’s acclaimed world-wide consulting services division. 

Nick Malik… Enterprise Architect for Hire.

I’ve been a consultant before.  In fact, in the 26 years since I graduated from college, I’ve spent more time in consulting than as an employee.  In some ways, I’m coming home.  However, I’ve not consulted through Microsoft’s consulting division before.  I expect that customers of Microsoft expect different things of their Microsoft consultants than they do from their management consultants or software development consultants (the roles I’ve played before).  I have a transition to make, and in all honesty, I’m both excited and nervous about the change.  After all, I’ve been working in one environment (Microsoft IT) for the past eight years.  I expect that moving “outside the bubble” will be a move back into the real world… a world that has changed dramatically since I was last there.

Microsoft’s internal culture is all-encompassing.  First off, not many people have the opportunity to work for such a large IT division.  Microsoft IT has 4,000 full time employees and thousands more consultants and contractors.  There are offices in 100 countries, six large scale redundant data centers, and massive deployments of bleeding edge technology.  Microsoft IT is Microsoft “First and Best Customer,” which means that we get the first crack at new technology, whether it’s ready or not.  For example: Thousands of Microsoft employees are using Windows 8 for their normal working environment, and yes, our helpdesk supports Windows 8.  We have large teams, and many roles, and an IT budget in excess of $1B.  No, Microsoft IT is not a typical IT shop.

For all the excitement of working inside the cauldron of Microsoft, the noise inside the bubble drowns out the sounds of reality from outside the bubble. To counteract this,  I have always made an effort to reach out and speak directly to customers of Microsoft software and exchange practices.  I am a member of a small minority of IT architects who are engaged in that way.  Most of IT is focused on serving the large and needy community of companies known as Microsoft. 

That doesn’t mean that Microsoft IT is sheltered.  Far from it.  We have strong relationships with key partners and each of the large OEMs.  We work closely with some large customers as well.  Microsoft IT folks are part of those partnerships and there is continuous contact.  That said, the majority of contact between MSIT and the “outside” world is in direct support of our partners.  Let’s not forget that it is also valuable to speak with people who are NOT involved in making Microsoft successful.  To that end, I’ve been engaged to speak to folks from financial services, oil and gas, retail, government, and many more sectors.  Each wanted to know about some aspect of Microsoft’s internal architectural activities.  Each was willing to share with me their experiences, and their techniques, for developing Enterprise Architecture.

I always got a great deal of energy from these contacts.  In some sense, they were the highlights of any week where I got a chance to present to, and listen to, and learn from, our myriad customers from all over the world.  And that is why I’m making this move.  I’m going after the thing that I enjoy doing the most: providing value directly to companies and organizations around the world.

What does that mean for me?  It means that I will spend a good bit more time in airplanes and hotels.  It also means that I will be working continuously in new situations, trying to add value as an EA in different companies, in different ways.  It also means that I may get something started and not be around to see it come to full fruit.  I’ll miss that part. 

What does that mean for you?  If you are a company or agency that needs an Enterprise Architect, and you’d like to have me visit and spend some time with you, please drop me a line through this website and I’ll see what I can do to arrange things. 

I’m hanging out my shingle.  Open for business.

image

On the road to a Business Architecture Manifesto

by

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?

by

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

CobiT recommends an ARB?  Really?

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

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

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

But what is wrong with an ARB?

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

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

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

So what should we do instead of an ARB?

The replacement: The IT Governance Board

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

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

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

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

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

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

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

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

by

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

Graves’ trilogy: Analyst-Anarchist-Architect

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

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

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

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

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

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

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

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

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

Different Efforts, Different Results

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

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

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

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

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

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

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

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

Business Analyst and Business Architect as one person

In my prior post, I made the case that there are many differences between a business analyst and a business architect.  My 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

by

[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…

Time-to-Release – the missing System Quality Attribute

by

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

Different lists of criteria

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

So where do we get these lists of attributes?

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

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

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

The missing criteria

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

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

How is that quality?

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

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

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

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

So your priority may be, in this example:

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

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

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

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

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

How Enterprise Architects can cope with Opportunistic Failure

by

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

What is Opportunistic Failure?

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

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

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

The scenario works like this: 

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

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

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

Thoughts on Opportunistic Failure

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

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

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

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

 

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.