/2012

Nullam Vitae Nibh Un Odiosters

By |2012-07-31T17:23:43+00:00July 31st, 2012|Enterprise Architecture|

Quisque ligulas ipsum, euismod atras vulputate iltricies etri elit. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nulla nunc dui, tristique in semper vel, congue sed ligula. Nam dolor ligula, faucibus id sodales in, auctor fringilla libero. Pellentesque pellentesque tempor tellus eget hendrerit. Morbi id aliquam ligula. Aliquam id dui sem. Proin rhoncus consequat nisl, eu ornare mauris tincidunt vitae.

Vestibulum sodales ante a purus volutpat euismod. Proin sodales quam nec ante sollicitudin lacinia. Ut egestas bibendum tempor. Morbi non nibh sit amet ligula blandit ullamcorper in nec risus. Pellentesque fringilla diam faucibus tortor bibendum vulputate. Etiam turpis urna, rhoncus et mattis ut, dapibus eu nunc. Nunc sed aliquet nisi. Nullam ut magna non lacus adipiscing volutpat. Aenean odio mauris, consectetur quis consequat quis, blandit a nunc. Sed orci erat, placerat ac interdum ut, suscipit eu augue. Nunc vitae mi tortor. Ut vel justo quis lectus elementum ullamcorper volutpat vel libero.

Donec volutpat nibh sit amet libero ornare non laoreet arcu luctus. Donec id arcu quis mauris euismod placerat sit amet ut metus. Sed imperdiet fringilla sem eget euismod. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Pellentesque adipiscing, neque ut pulvinar tincidunt, est sem euismod odio, eu ullamcorper turpis nisl sit amet velit. Nullam vitae nibh odio, non scelerisque nibh. Vestibulum ut est augue, in varius purus.

Proin dictum lobortis justo at pretium. Nunc malesuada ante sit amet purus ornare pulvinar. Donec suscipit dignissim ipsum at euismod. Curabitur malesuada lorem sed metus adipiscing in vehicula quam commodo. Sed porttitor elementum elementum. Proin eu ligula eget leo consectetur sodales et non mauris. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Nunc tincidunt, elit non cursus euismod, lacus augue ornare metus, egestas imperdiet nulla nisl quis mauris. Suspendisse a pharetra urna. Morbi dui lectus, pharetra nec elementum eget, vulputate ut nisi. Aliquam accumsan, nulla sed feugiat vehicula, lacus justo semper libero, quis porttitor turpis odio sit amet ligula. Duis dapibus fermentum orci, nec malesuada libero vehicula ut. Integer sodales, urna eget interdum eleifend, nulla nibh laoreet nisl, quis dignissim mauris dolor eget mi. Donec at mauris enim. Duis nisi tellus, adipiscing a convallis quis, tristique vitae risus. Nullam molestie gravida lobortis. Proin ut nibh quis felis auctor ornare. Cras ultricies, nibh at mollis faucibus, justo eros porttitor mi, quis auctor lectus arcu sit amet nunc. Vivamus gravida vehicula arcu, vitae vulputate augue lacinia faucibus.

Ut porttitor euismod cursus. Mauris suscipit, turpis ut dapibus rhoncus, odio erat egestas orci, in sollicitudin enim erat id est. Sed auctor gravida arcu, nec fringilla orci aliquet ut. Nullam eu pretium purus. Maecenas fermentum posuere sem vel posuere. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi ornare convallis lectus a faucibus. Praesent et urna turpis. Fusce tincidunt augue in velit tincidunt sed tempor felis porta. Nunc sodales, metus ut vestibulum ornare, est magna laoreet lectus, ut adipiscing massa odio sed turpis. In nec lorem porttitor urna consequat sagittis. Nullam eget elit ante. Pellentesque justo urna, semper nec faucibus sit amet, aliquam at mi. Maecenas eget diam nec mi dignissim pharetra.

Proin Sodales Quam Nec Sollicit

By |2012-07-31T17:23:05+00:00July 31st, 2012|Enterprise Architecture|

Quisque ligula ipsum, euismod aturesit vulputate a, ultricies et elit. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nulla nunc dui, tristique in semper vel, congue sed ligula. Nam dolor ligula, faucibus id sodales in, auctor fringilla libero. Pellentesque pellentesque tempor tellus eget hendrerit. Morbi id aliquam ligula. Aliquam id dui sem. Proin rhoncus consequat nisl, eu ornare mauris tincidunt vitae.

Vestibulum sodales ante a purus volutpat euismod. Proin sodales quam nec ante sollicitudin lacinia. Ut egestas bibendum tempor. Morbi non nibh sit amet ligula blandit ullamcorper in nec risus. Pellentesque fringilla diam faucibus tortor bibendum vulputate. Etiam turpis urna, rhoncus et mattis ut, dapibus eu nunc. Nunc sed aliquet nisi. Nullam ut magna non lacus adipiscing volutpat. Aenean odio mauris, consectetur quis consequat quis, blandit a nunc. Sed orci erat, placerat ac interdum ut, suscipit eu augue. Nunc vitae mi tortor. Ut vel justo quis lectus elementum ullamcorper volutpat vel libero.

Donec volutpat nibh sit amet libero ornare non laoreet arcu luctus. Donec id arcu quis mauris euismod placerat sit amet ut metus. Sed imperdiet fringilla sem eget euismod. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Pellentesque adipiscing, neque ut pulvinar tincidunt, est sem euismod odio, eu ullamcorper turpis nisl sit amet velit. Nullam vitae nibh odio, non scelerisque nibh. Vestibulum ut est augue, in varius purus.

Proin dictum lobortis justo at pretium. Nunc malesuada ante sit amet purus ornare pulvinar. Donec suscipit dignissim ipsum at euismod. Curabitur malesuada lorem sed metus adipiscing in vehicula quam commodo. Sed porttitor elementum elementum. Proin eu ligula eget leo consectetur sodales et non mauris. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Nunc tincidunt, elit non cursus euismod, lacus augue ornare metus, egestas imperdiet nulla nisl quis mauris. Suspendisse a pharetra urna. Morbi dui lectus, pharetra nec elementum eget, vulputate ut nisi. Aliquam accumsan, nulla sed feugiat vehicula, lacus justo semper libero, quis porttitor turpis odio sit amet ligula. Duis dapibus fermentum orci, nec malesuada libero vehicula ut. Integer sodales, urna eget interdum eleifend, nulla nibh laoreet nisl, quis dignissim mauris dolor eget mi. Donec at mauris enim. Duis nisi tellus, adipiscing a convallis quis, tristique vitae risus. Nullam molestie gravida lobortis. Proin ut nibh quis felis auctor ornare. Cras ultricies, nibh at mollis faucibus, justo eros porttitor mi, quis auctor lectus arcu sit amet nunc. Vivamus gravida vehicula arcu, vitae vulputate augue lacinia faucibus.

Ut porttitor euismod cursus. Mauris suscipit, turpis ut dapibus rhoncus, odio erat egestas orci, in sollicitudin enim erat id est. Sed auctor gravida arcu, nec fringilla orci aliquet ut. Nullam eu pretium purus. Maecenas fermentum posuere sem vel posuere. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi ornare convallis lectus a faucibus. Praesent et urna turpis. Fusce tincidunt augue in velit tincidunt sed tempor felis porta. Nunc sodales, metus ut vestibulum ornare, est magna laoreet lectus, ut adipiscing massa odio sed turpis. In nec lorem porttitor urna consequat sagittis. Nullam eget elit ante. Pellentesque justo urna, semper nec faucibus sit amet, aliquam at mi. Maecenas eget diam nec mi dignissim pharetra.

Nunc Tincidunt Elit Cursus

By |2012-07-31T17:22:22+00:00July 31st, 2012|Enterprise Architecture|

Quisque ligula ipsum, euismod a vulputate a, ultricies et elit. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nulla nunc dui, tristique in semper vel, congue sed ligula. Nam dolor ligula, faucibus id sodales in, auctor fringilla libero. Pellentesque pellentesque tempor tellus eget hendrerit. Morbi id aliquam ligula. Aliquam id dui sem. Proin rhoncus consequat nisl, eu ornare mauris tincidunt vitae.

Vestibulum sodales ante a purus volutpat euismod. Proin sodales quam nec ante sollicitudin lacinia. Ut egestas bibendum tempor. Morbi non nibh sit amet ligula blandit ullamcorper in nec risus. Pellentesque fringilla diam faucibus tortor bibendum vulputate. Etiam turpis urna, rhoncus et mattis ut, dapibus eu nunc. Nunc sed aliquet nisi. Nullam ut magna non lacus adipiscing volutpat. Aenean odio mauris, consectetur quis consequat quis, blandit a nunc. Sed orci erat, placerat ac interdum ut, suscipit eu augue. Nunc vitae mi tortor. Ut vel justo quis lectus elementum ullamcorper volutpat vel libero.

Donec volutpat nibh sit amet libero ornare non laoreet arcu luctus. Donec id arcu quis mauris euismod placerat sit amet ut metus. Sed imperdiet fringilla sem eget euismod. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Pellentesque adipiscing, neque ut pulvinar tincidunt, est sem euismod odio, eu ullamcorper turpis nisl sit amet velit. Nullam vitae nibh odio, non scelerisque nibh. Vestibulum ut est augue, in varius purus.

Proin dictum lobortis justo at pretium. Nunc malesuada ante sit amet purus ornare pulvinar. Donec suscipit dignissim ipsum at euismod. Curabitur malesuada lorem sed metus adipiscing in vehicula quam commodo. Sed porttitor elementum elementum. Proin eu ligula eget leo consectetur sodales et non mauris. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Nunc tincidunt, elit non cursus euismod, lacus augue ornare metus, egestas imperdiet nulla nisl quis mauris. Suspendisse a pharetra urna. Morbi dui lectus, pharetra nec elementum eget, vulputate ut nisi. Aliquam accumsan, nulla sed feugiat vehicula, lacus justo semper libero, quis porttitor turpis odio sit amet ligula. Duis dapibus fermentum orci, nec malesuada libero vehicula ut. Integer sodales, urna eget interdum eleifend, nulla nibh laoreet nisl, quis dignissim mauris dolor eget mi. Donec at mauris enim. Duis nisi tellus, adipiscing a convallis quis, tristique vitae risus. Nullam molestie gravida lobortis. Proin ut nibh quis felis auctor ornare. Cras ultricies, nibh at mollis faucibus, justo eros porttitor mi, quis auctor lectus arcu sit amet nunc. Vivamus gravida vehicula arcu, vitae vulputate augue lacinia faucibus.

Ut porttitor euismod cursus. Mauris suscipit, turpis ut dapibus rhoncus, odio erat egestas orci, in sollicitudin enim erat id est. Sed auctor gravida arcu, nec fringilla orci aliquet ut. Nullam eu pretium purus. Maecenas fermentum posuere sem vel posuere. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi ornare convallis lectus a faucibus. Praesent et urna turpis. Fusce tincidunt augue in velit tincidunt sed tempor felis porta. Nunc sodales, metus ut vestibulum ornare, est magna laoreet lectus, ut adipiscing massa odio sed turpis. In nec lorem porttitor urna consequat sagittis. Nullam eget elit ante. Pellentesque justo urna, semper nec faucibus sit amet, aliquam at mi. Maecenas eget diam nec mi dignissim pharetra.

Will Enterprise Architecture Ever “Cross the Chasm?”

By |2012-07-26T16:29:02+00:00July 26th, 2012|Enterprise Architecture|

The profession of Enterprise Architecture is beginning to emerge from its early stages of development. The number of people professing the title of Enterprise Architect has grown from a relative few in the 1990s to thousands today. On LinkedIn, a popular social networking site for professionals, the “Enterprise Architecture Network” discussion group boasts over 79,000 members.

There is a great deal of demand for Enterprise Architecture services. Large consulting firms like Accenture, Deloitte, PWC, and Wipro, large software vendors like Microsoft and IBM, large hardware vendors like Fujitsu and Hewlett Packard, and outsourcing firms like Computer Sciences Corporation, have all developed service offerings that revolve around providing Enterprise Architecture as a service to their clients.

While the field has grown, the proliferation of voices, methods, frameworks, and generally inconsistent advice in the field of EA has also grown. The number of “EA Frameworks” has grown to include a wide array of overlapping bodies of work. Included in this list are GERAM, TOGAF, FEAF, MODAF, DODAF, PEAF, E2AF, Zachman, and many others. Jaap Schekkerman has released three editions of his 250+ page book “How to Survive in the Jungle of Enterprise Architecture Frameworks” which attempts to compare only 15 of them!

Unfortunately this proliferation has created a problem that is common among emerging professions: a lack of maturity. As Geoffrey A. Moore pointed out in his landmark book, “Crossing the Chasm,” the market for a high-tech product will self-segment into Early Adopters (accounting for less than 20% of the market) and the more pragmatic customers in the Early Majority, Late Majority, and Laggards categories. Viewing Enterprise Architecture as a new high-tech product provides useful insight into why EA has failed to “cross the chasm” from early adoption to the pragmatic majority.

In order for Enterprise Architecture to cross the chasm, there has to be an intentional strategy to gain a foothold in one target market that is part of the Early Majority, and then to use the success of Enterprise Architecture in that space to build the credibility needed for other segments to adopt.

Unfortunately, while EA has been successful in some target markets in the Early Majority (like Telecom and Federal), the lack of consistency in the approach, terminology, and even value proposition of EA across industries poses an obstacle for increasing EA adoption. In other words, the success of EA in one or two areas is failing to help EA gain a foothold among other industries. Could it be because they don’t use the same words to describe success?

Unable to depend on a broader “EA movement,” each EA team is waging a lonely struggle for relevance and ongoing support within their own enterprise. To remain relevant, EA teams have often focused on “low hanging fruit,” immediately valuable initiatives that generate results quickly but often fail to address long-standing challenges. The mantra of modern Enterprise Architecture has become “provide immediate value immediately,” a position that relegates long-term thinking and investment to another day. Ironically, it is this long-term thinking and investment that EA is supposed to provide.

It should come as no surprise that a profession that is designed to provide value in the long term is struggling with demonstrating short-term results. Many EA programs fail as a result of this struggle. In a widely publicized study commissioned by EA tools vendor IDS Sheer, Jonathan Broer, then an undergraduate researcher from Rotterdam University, conducted a study of 191 organizations. The startling results of his survey suggest that up to 66% of all EA-sponsored efforts have failed to produce the expected results. Of the root causes cited: the lack of business awareness of Enterprise Architecture, lack of executive and stakeholder support, and the inability to provide a rapid return on investment.

There have been a few studies designed to examine the reason for the lack of EA to deliver rapid value. There have been no studies developed to examine the reason that EA success in some sectors have failed to translate to others.

In summary, EA stands at a crossroads. The profession of Enterprise Architecture is plagued by multiple problems.

  1. Enterprise Architecture is poorly defined by a wide array of discordant opinions, overlapping and industry-specific frameworks.
  2. Enterprise Architecture is hobbled by an inability to build momentum among Early Majority companies on the adoption curve.
  3. Enterprise Architecture has responded by focusing on the wrong set of problems: describing short-term-quick-win initiatives using methods and tools designed to produce long-term value.

Positioning an Enterprise Architect for Success

By |2012-07-09T17:45:28+00:00July 9th, 2012|Enterprise Architecture|

As I found in our Enterprise Architecture team in Microsoft, each time an Enterprise Architect is assigned to a specific area of the business, each one has a unique “engagement” with their stakeholders.  In very large organizations (like mine), there may be many different IT units as well as many different business units, all involved in a particular strategy.   Each situation is different.   This leads to a common problem that can framed with two questions:

  1. So how do you know if your Enterprise Architect is doing a good job?
  2. How do you set the right expectations to position that Enterprise Architect for success?

A Model for Positioning an Architect

We developed a simple grid that helps to position the EA with respect to a specific area of the business.  The two axes of the grid are: Architectural Maturity of the “segment” and Maturity of the Architectural Engagement itself.  Within each cell, we put a description of “what we want the EA to do” if they find themselves in that position.

Note that maturity of the engagement is a measurement of a relationship: specifically the relationship between the “business customer” and the Enterprise Architect.  Architectural maturity of the segment is measured against both the business area and the IT groups that they use (see below).  You need to measure the maturity of BOTH variables in order to understand what an Enterprise Architect will need to do to be effective.

image

Note that the Architectural Maturity axis has four levels, cryptically described as “Level I” through “Level IV”.  This is a reference to our internal maturity model, which I’m not at liberty to share in detail. 

The broad strokes are:

  • Level  I – architecture is not a trusted and well-understood role in business change or IT programs.  (This includes business, information, solution, and technology architecture).
     
  • Level II – architecture is used and their processes are defined, but not consistently and not well. 
     
  • Level III – architecture is performed consistently and is part of governance as well as some portfolio planning activities.  The business stakeholder does not take ownership of driving the funding and execution of the roadmaps developed by the Enterprise Architect.
     
  • Level IV – architecture is performed consistently and is involved in planning and governance.  The business stakeholders involved in funding and overseeing the business changes themselves are engaged with enterprise architecture, have been key in developing the roadmaps, and follow through with regular updates to the future state models and the roadmaps.  In addition, they decide on which initiatives to use BASED ON the content of the roadmaps. 

 

Using this model

I’ll provide two scenarios to illustrate how this simple grid is used. 

In Fabrikam, we are Enterprise Architects.  Fabrikam manufactures and distributes consumer electronics.  There are six divisions that manufacture different kinds of products (kitchen appliances, television and radio, automotive, etc). Let’s say that we have 18 Enterprise Architects in our EA team.  Fabrikam’s EA has divided into three working groups, each with six architects.  Maria manages one of these teams, and has six enterprise architects working for her.  Her team focuses on addressing business issues related to supply chain management. 

Maria is performing an annual review for two of her architects.  They are Tomas and Jai. 

Case 1: Tomas

Tomas is working with the kitchen appliance team.  This is the oldest division in Fabrikam, and they have their own IT group that has been stable for many years.  That team has established processes for IT architecture but no business architecture.  Their architectural maturity is Level III.   Tomas just moved over to the kitchen appliance division from the television and radio division.  He is a well established architect with years of experience, but the kitchen appliance team is just beginning to get to know him.  As a result, the maturity of the engagement is “Useful.”  

The intersection of these axes has the following text:

  • Engage in existing review and governance processes
  • Engage stakeholders in cross business decisions
  • Collect current state data

Maria can set expectations with Tomas and with the Kitchen Appliance division.  Tomas will be expected to engage in existing governance and review processes.  He will be expected to work with business stakeholders in the kitchen appliance team as well as other divisions to address shared opportunities, capability overlaps, and strategic prioritization.  He will be expected to collect current state information models, system models, technology models, and business strategies for the EA repository.  He will be measured on his ability to deliver on these expectations.

Case 2: Jai

Jai is working with the automotive division.  This is the newest division in Fabrikam, and they are just beginning to roll out their first set of after-market automotive radios and CD players in the North American market.  Their IT division is small and rather chaotic.  Their architectural maturity is Level I.  Jai has been working with the automotive division for about two years, and has repeatedly earned recognition from their business leaders for his skill and depth of knowledge.  The maturity of the engagement is “Influential".

The intersection of these axes has the following text:

  • Demonstrate EA specific methods and deliverables
  • Drive the scoping, approval, and oversight of an enterprise-relevant project

Maria can set expectations with Jai and with the automotive division.  Jai is expected to demonstrate EA specific methods and deliverables.  The teams know him and trust him.  He can demonstrate how EA can be valuable by simply doing the work and showing how valuable the results are.  Due to his level of influence, he can work with the business to invest in an area of improvement that will benefit the entire enterprise (for example, a project to improve the distribution of finished goods to retailers), and then work with the IT teams and business stakeholders involved to get the project launched and oversee its development.  Jai can be measured on his ability to deliver on these expectations.

Conclusion

In small organizations, Enterprise Architects can be “heros” and just “do what works,” but if you are trying to develop a mature EA program, each architect needs to have specific goals and specific deliverables that they will be expecte
d to deliver.  This kind of model, we found, is useful for helping each architect to position themselves and their role in the organization.

Conversational Antipatterns on Message Boards

By |2012-06-22T14:07:59+00:00June 22nd, 2012|Enterprise Architecture|

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 c
ontributions.  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 |2012-06-14T02:29:07+00:00June 14th, 2012|Enterprise Architecture|

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

Three Schools of Thought for Enterprise Architecture

By |2012-05-28T02:17:00+00:00May 28th, 2012|Enterprise Architecture|

It is interesting to watch the debates online between the different schools of thought of Enterprise Architecture.  The discussion was started by James Lapalme, who published a paper on “three schools of thought” which is in pre-print for the IEEE’s IT Professional journal.  (citation)  Mostly the online discussion focused around the role of the newest domain of Enterprise Architecture… the domain of Business Architecture.  Depending on how Business Architecture is understood, the role of EA can be dramatically different.

  • Some say that EA is about improving IT. In the diagram below, this is “Enterprise IT Architecting.”  In the online groups, we call this EITA.   In this model, EA is a mechanism for designing IT services and creating IT systems that address enterprise needs. It’s just a bare step above Enterprise Application Architecture by operating outside the constraints of funded projects, but the impact occurs in IT.  For this first group, Business Architecture is just another name for Business Analysis.
     
  • Others say EA is about aligning the business with all of its capabilities, including IT. For these folks, Business Architecture exists, but it’s primary impact is internal. Business Architects insure that the right initiatives are created in order to achieve business strategy. In the diagram below, this is labeled “Enterprise Integrating.”  In this school of thought, Business Architecture doesn’t really impact business strategy. Business Architecture uses capability analysis to understand the impacts of strategy on the business processes and systems, and helps to frame the initiatives that should be created. Only after the initiatives are started would a business analyst even get involved. In this model, EA provides all the benefits of the first group, AND insures that investments are made in the right place.
     
  • A third group say that EA is about Enterprise Ecological Adaptation. For these folks, Business Architects help analyze the movements of the market, and work closely with business leaders to develop strategies based on the capabilities and positioning of the company that are likely to generate new revenue, improve market position, improve customer loyalty, and reduce costs.  EA and Business Architecture help the business adapt to the ecosystem in which it exists.  In this model, EA provides all the benefits of the first two groups, AND insures that the business responds to the market conditions in a logical manner.  For some in this camp, Business Architects are not even part of EA.
     

Depending on the company your work in, there’s a case to be made for each. Personally, I prefer to think of EA as alignment at the minimum, and strategic effectiveness as an ideal state.  I created the following image to illustrate these distinctions.  For further reference, please read James Lapalme’s paper in the IEEE IT Professional journal.

image

Setting Up A New EA or BA Practice

By |2012-05-20T12:49:00+00:00May 20th, 2012|Enterprise Architecture|

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.

 

  1. 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. 
  2. 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.
  3. 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. 
  4. 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. Be prepared to rewrite the value proposition.  The value you deliver must be tied to the needs that they express.
  5. 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. 
     
  6. 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.