EA Tips – Style AND Substance

For an EA practice to be effective EA leaders must pay attention to both the “style” of how their team operates and the “substance” of the work they produce. While that guidance isn’t new, in practice I often find that many leaders don’t have the balance quite right. It is worth revisiting as a general EA Tip.

First, what do I mean by “style” and by ‘substance”? (note: I chose those words because it sounded like a catchy blog title) For the sake of this article, I define “substance” to be the “work product” of the team as viewed by EA consumers wanting hard deliverables like frameworks, models, standards, roadmaps, strategy papers, and other related content. “Style” refers to “how” the team works with the rest of the organization in creating and utilizing their content: engaging business and IT leadership, fostering a collaborative environment; choosing communications vehicles, the words they use, and the “posture” of how they present themselves to the rest of the organization.

Many EA teams disproportionately direct more effort to the substance of the work than to building a sense of ownership and socializing the desired changes. In essence, they under serve the “style” elements. Granted, substance is critical. No matter how good the soft skills are or how convincing the leaders are, if the content isn’t solid then nobody will follow. But what is more surprising to many teams is that even the most elegant and perfect deliverables often don’t have impact. Why? – Because the team hasn’t positioned the larger workforce to embrace enterprise architecture content and to use it in their day to day work.

Improving the EA team’s style is often where we spend time with clients, specifically working on the “art” of practicing EA. Though many EA’s wish there was a methodological approach to these softer elements, there really isn’t one that works in all cases. People, perspectives, culture, and individual skills vary widely from organization to organization. One approach is to look to lessons learned from the organizational change management discipline, particularly as they apply to driving change across and down into an organization. There are tried and true techniques for preparing organizations for change, conducting education and awareness campaigns, gaining support and participation, and communicating effectively through a variety of different channels. After all, one of the valuable outcomes from EA is helping an organization move from an emphasis on tactical execution and silo behaviors to one that includes a larger, enterprise-wide strategic element. Substance is great, but style really does matter.

Hold the Date! – George Paras Keynote at Denver IASA ITARC on May 6, 2010

In a keynote presentation at the upcoming IASA ITARC Denver Event I will be discussing  the leadership challenges that many current and aspiring IT leaders face in their organizations, and how they can overcome those challenges by applying selected enterprise architecture concepts to their decision-making framework.  Not surprisingly, I advocate moving EA “upstream” within the management structure and expanding the context to make it more relevant to the business.   Doing so isn’t easy.  It requires a combination of skills in leadership, process integration within the Office of the CIO, and appropriate content in business and information architecture.   In this session attendees will learn how to get started on this journey.  

If you are in Denver and plan to attend, please let us know.  We’ll be available to discuss  ideas with any organization interested in expanding the scope and reach of their EA practice into business-oriented EA. 

The International Association of Software Architects (IASA) is the premier association focused on the architecture profession through the advancement of best practices and education while delivering programs and services to IT architects of all levels around the world.  The IT Architect Regional Conference is the first event in Minnesota to address the pressing needs of IT architects today. There are 12 seminars and two tracks separated by specialty: Enterprise and Fundamentals. Architects of all levels can take their skills to the next level.

Tips for Creating Domain Architecture Documentation

Domain Architecture documents are one of the most widely created, and probably the most misunderstood, of the various EA deliverables an EA team might have in their document repository.  As we visit EA teams we often discover these documents in various states of disrepair, from perpetual draft, to complete but out of date, to a minimalist listing of product standards, to over-written tutorials on topics long ago commoditized or no longer relevent.  

We were recently asked by a client to clarify the latest thinking on these documents.  Are they still relevent, who are they for, and what value to they deliver?   The short answer is that the thinking on domain documentation has not fundamentally changed, though it has matured a bit.  The focus these days is on determining what that documentation is for, who uses it, and what other documentation is required in the set of deliverables an EA team could produce. 

First, a couple of caveats: When deciding what documents to create, the most important thing is to make sure you will be able to maintain them.   Also, it is important to understand who the users of each document are and to structure accordingly, to understand the relationships between different deliverables, and to have an appreciation for the absolute and relative value of each deliverable.  We are biased to invest heaviest in documents that are prescriptive for external stakeholders, while putting tangible (though less) relative value on deliverables used internally to the EA group (and invest more when they are foundational to other higher-valued deliverables). 

Domain documentation is one of those areas that cross a couple of boundaries of the caveats just described, providing value at different levels: 

1)      The primary audiences for technical domain documentation is the EA group itself and its extended SME community responsible for the asset categories contained in the specific domain.   As such, in and of themselves any given domain document has somewhat narrow prescriptive appeal to include primarily those that, for example, select, operate, maintain “platforms”, “networks”, “middleware”, etc.

2)      The primary content of domain documentation is design principles, categories, standards, products and configurations, including specific use-case descriptions for when and how to select them – as we have historically described.

3)      Taken together, the collection of technical domain documents contain “parts” or “building blocks”, and through the use-case scenarios and design principles, become components of higher-order constructs like “patterns” (e.g. infrastruture or development) or “platforms” (e.g. application).  These patterns deliver higher-order value, consumable in the direct construction of solutions.  The domains, in turn, have foundational value because they inform the consistent creation of the patterns as common building blocks.

When creating traditional Technical Domain Architecture documents, many organizations opt to organize around a Technical Reference Model (like TOGAF’s TRM), create a product lifecycle (standard, obsolete, research, sunset, etc.) model in spreadsheets, or create product/standard roadmaps (as we have discussed in the past).  These lack the degree of detail of domain architectures, and frequently do not include helpful use-case information.  They tend to be product/release-specific and less prescriptive to stakeholders other than the asset owners.  Nonetheless, they do tend to satisfy the audience of consumers that want answers to “what product do I use?” questions. 

Our bottom-line recommendations:

• Do not over-invest in domain documents, yet they serve an important purpose – foundationally, for the EA team, and for SME asset owner communities. 
• Make sure the authors are creating tight, prescriptive deliverables geared to the specific stakeholder community. 
• Make sure that the authors are not writing lengthy tutorials – these are not educational documents.   
• Recognize that the creation of higher-order patterns, etc. will absolutely require cross-domain collaboration, so it is best to avoid compartmentalizing domain document development to just those knowledgeable about the subject matter.   
• Also, realize that different domain documents will, from the very nature of the topic (revolutionary, or commodity), require different levels of specification and detail.  Don’t try too hard to make them all exactly equal.

TOGAF 9.0 Released February 2, 2009

The Open Group announced the release of the latest version of The Open Group Architecture Framework (TOGAF), 9.0, during the 21st Enterprise Architecture Practitioners Conference in San Diego this week. It is available for download at http://www.opengroup.org/architecture/togaf/.

During a briefing with The Open Group representatives last month, EAdirections learned about the improvements and additional components of TOGAF 9.0:

o The Architecture Content Framework, contributed by Capgemini, is a structured metamodel for architectural artifacts, intended to help an organization organize and relate the artifacts that they create. This is different than the reference models, TRM and III-RM, as they are targeted at organizing and related topical areas.
o The Architecture Capability Framework is intended to provide better guidance in the area of skills, organization, roles and responsibilities of architects, and a process for defining an appropriate architecture capability for your organization.
o Enhanced guidance on the usage of the Architecture Development Method, including the use of iterations, partitioning, applying TOGAF to different levels of architecture, and dealing with the specifics of different architecture styles, specifically security architecture and SOA.
o More, both explicit and implicit, improvements in the positioning of TOGAF as a toolset for ENTEPRISE architecture …. which, of course, we will be very interested in.

TOGAF has fundamentally not changed. The views, definitions, and perspectives that have characterized TOGAF for many years are the same. We have spoken to our impressions of TOGAF in support of Enterprise Architecture efforts many times, most notably in a webinar and corresponding survey in September, 2008. Our initial impressions of TOGAF 9’s changes are that they are all steps in the right direction, without having looked at the details yet. We will be conducting a more detailed review and making our findings know in the second quarter of 2009. If you have questions between now and then, don’t hesitate to contact Tim Westbrock at twestbrock@EAdirections.com.

Directions: EA practitioners should be aware of and investigate the features of TOGAF 9, with an eye towards the continued evolution of TOGAF as an EA toolset.