When I was six years old, I visited an old worker and his lifetime job was to craft beautiful nails for handmade wooden doors. His theory was that a good nail head must be made with just seven blows. But, he added, “There is no good worker without good tools”. His words made such an impression that I’ve never forgotten them.

Enterprise architecture is still a young discipline; the most advanced enterprises and professionals still have less than 10 years of experience in it. Firms still need to make various compromises when building a “good-enough” architecture within their organization – i.e., one that does not cost too much nor delays project delivery, but maintains a manageable level of coherency and complexity despite organizational (or political) complexities. A survey published in 2006 reveals that 53% of EA stakeholders see EA documentation as hard to find and use, 42% think the documentation is not specific enough, and 34% believe that EA is not involved with the business.

Starting a new architecture initiative in an enterprise that does not have it or enhancing current EA practices that can’t satisfy new objectives remains a challenge. Firms can make improvements in many ways; choosing the right combination of improvements is difficult.

One of the best practices collected from Forrester’s EA group research is that bringing coherency to EA requires aligning three dimensions: organization, objectives, and EA scope. Bringing coherency involves a progressive approach of better understanding and sharing EA knowledge -- not just within the EA group, but also with EA stakeholders like business relationship managers, operation and development groups, the CIO, and even IT procurement in some organizations.

This book provides a number of the “good tools” that will help architects make the right choice, demonstrate why these are the right choices, and find the right progression path. They will thus become the “good” -- or at least a better -- enterprise architect than the one without these tools, recognizing of course, that our architects are knowledge workers rather than manual ones! This book mainly describes the use of four tools and provides numerous tips and examples:

The first of these EA tools is the DYA architecture framework. An EA framework is a graphical, abstract representation of EA content, such as the different models, a breakdown of the details, and sometimes the viewpoints. Enterprise architecture frameworks are well-known among architects: 55% use their own custom frameworks and a further 30% use Zachman. There are more than 20 EA frameworks available on the market, ranging from extremely simple to highly complex. Choosing a framework is a best practice that enables architects to represent elements like their EA coverage and the boundaries of the responsibilities they share with business units, and to illustrate their progress with simple indicators like red lights.  

The second EA tool described here is the SWOT Analysis Process, based on a survey of EA users. Architects often work in two ways: as firemen or as policemen. A good architect is continuously alternating between these roles and adding yet others, like insurer. He must find the right balance between thought and action, but just how to go about this is often difficult to establish. The SWOT Analysis Process is a unique tool because it assesses the view of those using the architecture and provides recommendations on how to move in the right direction and find a better balance between the fireman and policeman roles.  
The third of the EA tools proposed is the Architecture Maturity Matrix. This helps prioritize where you should put the emphasis, as it is impossible to do everything at once. The use of this relatively new type of EA tool -- often called enterprise architecture assessments -- is not yet a best practice, as a recent survey showed us. Currently, they are used mainly by the most advanced organizations, with many using them repeatedly to assess their next steps – thus demonstrating their value. As a result, this is the tool that most organizations should adopt next.  
Finally and most importantly -- and what really makes the difference in the market -- is the description of a methodology with examples. Even if these different tools can be used individually, the methodology links these different tools in a framework. It helps architects create their own irreplaceable experience of correctly using the tools by giving the reader some of the important “know-how”, including how to tailor these tools to obtain a better nail -- sorry, a better enterprise architecture! -- for your enterprise.   

There are a number of other tools in this book beyond those I’ve included in this foreword, but it would be far better for you to discover these by actually reading the book. The appearance and developing usage of these tools and best practices demonstrate that the enterprise architect role is maturing. I hope that reading this book will make you a better-armed enterprise architect, with a wide range of good tools at your disposal.

 

-- Henry Peyret, Senior Analyst at Forrester Research
Forrester Leadership Board EA Council