Enterprise Architecture Turnaround

© Copyright 2011 APOORVA Corporation.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the written prior permission of the author.

ISBN: 978-1-4669-0697-6 (sc)

ISBN: 978-1-4669-0695-2 (hc)

ISBN: 978-1-4669-0696-9 (e)

Library of Congress Control Number: 2011962031

Trafford rev. 12/08/2011

7-Copyright-Trafford_Logo.ai    www.trafford.com

North America & international

toll-free: 1 888 232 4444 (USA & Canada)

phone: 250 383 6864  

  fax: 812 355 4082

Contents

Foreword

Acknowledgements

Introduction

CHAPTER 1

Why Are There Problems with Enterprise Architecture?

Chapter 2

Current State & Survivability

Chapter 3

Seven Elements for Architecture Turnaround

Chapter 4

IDEA Framework:

A Foundation for Enterprise Architecture Turnaround

Chapter 5

IDEA Framework Part II: Deliverables in Detail

Chapter 6

The Architecture Plan:

Seven Elements +

IDEA Framework

Chapter 7

References

Notes

to those

who taught us

great lessons of life

and have stayed by our side

Foreword

In over 40 years as an IT professional I have served in virtually all aspects of the profession: programming, operations, network management, security, architect, all levels of management. I have worked in small organizations as well as large ones including IBM, FedEx, DHL, and MCI. Recently I have served as an EA consultant to several Federal Government agencies. All this really means is that I have first-hand experience with what works; and what does not. I have known and worked with Dr. Anupindi and Mr. Coady for over 10 years. They too have been around the block a few times. So when they asked me to write the foreword I expected a serious book. In that respect I was not disappointed.

When I received the manuscript my first thought was oh great, an Enterprise Architecture (EA) self-help book with yet another framework.; more snake oil applied with a large dose of architecture babble. For this thought, I owe Dr. Anupindi and Mr. Coady my humble apology. What I found instead was a thoughtful and realistic approach to establishing (or remediating) an Enterprise Architecture program. What differentiates this book from other EA books is that Anupindi and Coady provide a step by step process to implement their IDEA Framework. Other books leave the application as an exercise to the reader. The other differentiating factor is the authors cut through the lofty rhetoric that so often accompanies EA literature. This is not an ivory tower work, it is actionable, applied Enterprise Architecture.

It is also a healthy dose of EA tough love. After a brief history of EA, one runs head-on into Chapter 2—Why Are There Problems with Enterprise Architecture? If you want to know why EA fails, read this chapter. It is introspective, it does not blame external forces (the not my fault syndrome). It also does not blame, in fact it hardly mentions, technology. To be fair, the authors do recognize external influences; however they are viewed as risks that must be managed. According to Anupindi and Coady, failure in EA is attributable to a LACK OF 1) Leadership, 2) Skilled and enthusiastic staff, 3) a Budget, 4) a Plan, 5) Marketing/Communications and/or 6) Repeatable Architecture processes supported by tools (read Framework). A common thread in this chapter is the realization that EA must not only manage these variables, but also that these variables do not exist in isolation. EA exists in a corporate eco-system, failure to recognize, protect and grow relationships is the primary cause of EA failure.

I found it interesting, and refreshing, that the authors did not spend much time discussing Enterprise, IT and EA strategy. They have been around the block a number of times and recognize that the vast majority of US enterprises and their IT departments do not have an executable strategy. Therefore trying to align Enterprise and IT strategy is a loosing proposition. But they do have an IDEA as how to avoid this trap. Anyway, as Hamel and Prahalad note in Competing for the Future, most business suffer from . . . Ambitious long-term goals and detailed, short-term budgets, with nothing to link them together. For an enterprise with this problem, I often find an IT department with an ineffective IT strategy, or an IT strategy that is highly cost focused; this is IT as a cost center as opposed to IT the strategic business partner.

In true self-help/tough love form, chapters 4 and 5 concentrate on gap analysis, this was observed in Chapter 2 Problems and a set of Seven (7) Elements which they call soft skills that will drive EA Turnaround. This chapter is, deceptively, one of the more important chapters in the book. While fairly common to the business world, they are often in short supply in the IT community. Unless close attention is paid to these soft skills, even the best technical cadre will fail. Indeed, many books have been written about these elements; Anupindi and Coady have provided an excellent précis of a vast volume of literature; an unexpected bonus. Further, instead of a dry summary, they have provided the reader with a description of intersections among the elements. The 7 Elements are:

1.   Leadership

2.   Relationships

3.   Projects

4.   Organization

5.   Product

6.   Budget and

7.   Processes

Personally, I would like to see the authors expand this chapter into a sequel to the current book. Up to this point the authors have helped us understand and diagnose the source of many EA failures. They have provided us with an understanding of the Elements that we must master to be successful. Good place to stop. Anupindi and Coady don’t work that way. Instead they have chosen the other path. That path includes a new framework; and more importantly a set of detailed deliverables (architecture the noun) coupled with an integrating process (architecture the verb). This is their IDEA, their innovation.

The heart of the book is the IDEA, the Investment Driven Enterprise Architecture Framework. The purpose of the Framework is to provide guidance on how the corporation’s future technology will be drafted and communicated. While the goal is familiar, the process for achieving it is very different. First, it does not require an executable, enunciated strategy at either the corporate or IT level. Second, it is actionable by design. As good architects, there is a bit of inventory and categorization; but that is the means, not the ends. The IDEA is to be necessary and sufficient; one does need to know everything. Anupindi and Coady have cleverly avoided the strategy and vision trap by basing IDEA on IT Investments. In that respect, they have integrated IT Portfolio Management concepts with Enterprise Architecture concepts. It is a simple, yet powerful approach.

Even if an IT organization does not have an actionable strategy, one may nevertheless infer one by analyzing Past and Current Investments. Now you know what technologies your IT department is investing in. Unless things change, this also informs the EA as to what Future Investments will have to look like. Now, the authors have proposed 10 deliverables to implement the three tracks of IDEA.

Deliverables for Past Investments include an Architecture Repository (data warehouse for IT assets), Change Impact Analysis and Fault Tolerance. Basically what do you have, what are you changing and what is failing. This simply helps IT get control of its environment. If you can’t measure it, you can’t manage it. Now you can measure it. If it isn’t working, now you can actively plan future investments to resolve business (or IT) problems.

Deliverables for Current Investments are designed to introduce efficiencies in the purchasing and implementation of IT Infrastructure. Architecture Service Estimates establish the technology areas that are required to implement a solution (and by default eliminates those that are not). The Technology Architecture Design creates a blueprint for how the technologies must be integrated to provide the solution. This includes size, availability, security, performance and other dynamics that the implementation team must manage. It provides a common, transparent understanding for both the Business and IT team members. The Hardware & Software Cost Estimates provides cost estimates. The key here is that Enterprise Architects, Solution Architects and Technical Architects collaborate on these documents. This provides a consistent basis of estimate on all projects. This allows IT Management and/or a Project Management Organization to deal with budget allocation questions. Lastly, the Development Ready Assessment. This is first a risk management document; have the risks been identified and mitigated; is the project ready for implementation. Secondly, it assesses how well the project has been managed from a technology and integration aspect. It goes to the question of organizational efficiency and integration.

The third track, Future Investments, is an opportunity to plan IT investments as opposed to just letting them happen. Past Investments tell the EA where the organization is spending its IT dollars. These are your de facto standards. Technology vendors routinely publish product roadmaps. Merge these roadmaps with your investment base and you now have your Technology and Application Roadmaps.

At this point Anupindi and Coady have established a foundation for establishing or turning around an Enterprise Architecture program. Most would be happy; not them. They will not leave this as an exercise to the reader. In the final chapters the integrate the Seven Elements from Chapter 4 with the IDEA Framework from Chapters 5 and 6. As the book title proclaims, this is about Turnaround. Here they apply principles commonly used to bring a failing business out of bankruptcy; they are now turnaround specialists. This chapter provides a step by step process for building an executable business plan that integrates the soft skill requirements of the Seven Elements with the technical skills of the IDEA Framework. Here you learn how to build an executable EA Strategy, how to define and measure success; and how to build a coherent tactical plan that fits within financial constraints. This is your agreement with your stakeholders, what you need from them, what you will provide for them.

The IDEA Framework describes your primary deliverables. In this chapter the authors provide you with tips on how to produce them. Here you will also find useful tips on Organizational Formation and Change. To be successful you will need to understand your Critical Business Processes and how they are integrated to form an Operational Plan. And no matter how well you execute, a busy organization will ignore you. Therefore Marketing and Communication are critical success factors. Lastly, the business essentials; Budgeting and Financial Projections, Tasks and Projects for Rebuilding EA all coupled with Risk Assessment and Management. On time, On budget, No surprises.

Make no mistake about it; this is not an easy read. Anupindi and Coady are serious people with a serious message. If your EA program is in trouble, you need to understand and internalize the concepts put forth in this book. In over 40 years as an IT professional, this is one of the few books that provide an actionable plan for establishing or turning around an EA Department.

They open the hose early and they don’t turn it off.

Michael Bates

Conifer, CO

Acknowledgements

We must thank our family members Anupama, Rachael, Kusala, Thomas and Komala. When we started writing this book, we thought that we had started on a heroic journey that would make all our family members very proud. Half way into the book, we realized that this venture could only be completed by sacrificing time with our families. We promise them no such ventures will be started in the future without prior consultation, as well as lots of prepaid pampering and domestic chores.

We thank our well-wisher, Audra Reid, who has been equally excited to get this book published. She has engaged in various tactics, from reasoning to threatening, to make us work on the book. Our sincere thanks go to Sandra Keifer-Roberts for editing a manuscript that was written by two foreigners from two different continents with vastly different cultures. It goes without saying that Thomas Hortman bestowed his knowledge to help fine tune the manuscript.

We thank our friends Jonathan Adams, Jan Fogelberg, Srinivas Kolluri, Raghuram Madapati, Ryan McIntyre, Shravan Miriyala, Corey Hessen, Srinivas Sonti and Dennis Stephens for helping us with many aspects of our life. They are the inspiration for all the feathers in our hats and they are the guardians for fewer bruises on our face.

Our special thanks go to Michael Bates, our dear friend and a great leader that mastered the Enterprise Architecture discipline. He can explain all the EA Frameworks better than those that created them. He has an inbuilt skill to narrate the pros and cons with lively stories. We are honored to have is Foreword in this book.

We thank people who spent many hours with us in the Enterprise Architecture discipline. We thank William Callaghan, Robert Chartier, Michael McCraken, Laurie McKitrick, Rob Rossi, Brian Scroggins and Robin Younkman for their great insights and thought leadership. They demonstrated the two basic ingredients of success: the discipline and the passion to build successful EA departments.

We thank our coworkers and mentors that touched our career-lives and pushed it forward towards our current state: Sridhar Adina, Stacey Alexander, Phanikumar Anupindi, Darryl Austin, Scott Carlin, Michael Carlson, James W. Cooley, Ahmet Corpaciaglu, Kathie Dudas, Mark Endry, Liam Fahey, Angie Fetter, Scott