Which Comes First, Strategy or Architecture?

November 2008 | Volume 4, Number 4 Special Issue – Enterprise Architecture Book Reviews Features Architect’s Spotlight: Waylon Krush Architect’s Toolbox: David Rice Architecture Book Reviews 6 8 13 Articles The Enterprise Architecture Reference Cube 35 Gundars Osvalds Which Comes First, Strategy or Architecture? 47 Tanaia Parker and Tyson Brooks Improving Government Performance Through Enterprise-Focused Development 59 Alex Glaros Case Study Focusing on Desired Outcomes to Formulate a CustomerValued Enterprise Management Strategy 70 Tyson Brooks and Jeffrey Wallk © Journal of Enterprise Architecture – August 2008 1 The Journal of Enterprise Architecture November 2008 Volume 4, Number 4 Features Editor’s Corner 4 a|EA Points of Contact 5 Architect’s Spotlight: Waylon Krush 6 Architect’s Toolbox: Metastorm’s ProVision: David Rice 8 Architecture Book Reviews 13 Articles The Enterprise Architecture Reference Cube Gundars Osvalds 35 Which Comes First, Strategy or Architecture? Tanaia Parker and Tyson Brooks 47 Improving Government Performance Through Enterprise-Focused Development Alex Glaros 59 Case Study Focusing on Desired Outcomes to Formulate a CustomerValued Enterprise Management Strategy: A Case Study Tyson Brooks and Jeffrey Wallk 2 © Journal of Enterprise Architecture – November 2008 70 Editor’s Corner Scott Bernard, Editor This quarter’s issue of JEA is special in that it has the first set of EA book reviews that we have ever done – I hope they are helpful to you. This issue is also the third one that is available to subscribers in electronic form… part of our effort to control costs and “go green.” There will remain a place for hardcopy (e.g.’ copies to reference libraries) but electronic copies are gaining rapid acceptance with our readers – in the first six months over half of our subscribers are choosing to go electronic. To further promote this, I am providing an electronic copy of this issue to all subscribers so they can see how easy it is to receive and read. So, how do you change? You can contact us via email ([email protected]) to switch a current subscription, or when next renewing your subscription you can designate that you want to receive a an electronic copy (via email) of the journal each quarter. Also, we will soon be posting former issues of JEA (those more than two years old) on the journal’s website for subscribers to access, so please visit us at www.aeajournal.org. As always, subscribing to JEA also provides a one-year membership to the Association of Enterprise Architects, as a member-at-large, or you can affiliate with a local chapter of a|EA if one is active in your area. The current subscription rates are: U.S. Domestic U.S. Domestic International International Electronic Copies Hardcopy Electronic Copies Hardcopy $50/year $80/year $50/year $120/year We have a great November 2008 issue that features Waylon Krush as our “Architect in the Spotlight”. Waylon is the CEO of Lunarline, Inc. – a Washington DC based security consulting firm that works with public, private, military, and defense sector clients. Waylon has been a thought leader in information security and related architectures for nearly a decade, and he has participated in a number of policy and best practice initiatives, including the development of the Federal CIO Council’s ‘Security and Privacy Profile’ that is part of the Federal Enterprise Architecture. Security is one of the aspects of enterprise architecture that continues to be under-developed and poorly integrated, and including Mr. Krush as our spotlighted architect is part of what will be an ongoing effort by JEA to emphasize the importance of this area. David Rice returns to JEA with a detailed review of Metastorm’s ProView™ tool that you will find helpful. Thank you David! In this issue we also have several excellent articles on EA theory and practice, including an interesting concept by Gundars Osvalds on an “Enterprise Architecture Reference Cube’ that includes a cube template that you can copy and cut-out (a very imaginative way to reinforce his concept). We also have an insightful article on the relationship between strategy and architecture by Tanaia Parker and Tyson Brooks, as well as a contribution from Alex Glaros on improving government agency performance through the use of an approach that he has termed “Enterprise-Focused Development.” Our case study is an interesting research piece from Tyson Brooks and Jeffrey Wallk that looks at how to “focus on desired outcomes to formulate a customer-valued enterprise management strategy.” It is not your imagination, Tyson Brooks contributed to two articles that appear in this issue – a JEA first! In September, as a representative of a|EA and JEA, I attended the largest public sector EA conference that is held each year in Washington DC, as well as the second annual European EA gathering in Copenhagen Denmark, that was sponsored by the Danish IT Society. Both were very interesting, well attended events and the feedback from many people was that a|EA is an increasingly popular global network of EA professionals and that JEA is a preferred source of paradigm and product neutral information on EA theory and practice. JEA continues to welcome announcements and ads for EA conferences globally, and we print them at no cost to the conference in order to further promote our growing profession. I hope you enjoy the November 2008 issue of JEA and I look forward to seeing our electronic subscription option continue to grow in popularity… it keeps costs down and reduces delivery time. Take care and Happy Holidays! © Journal of Enterprise Architecture – November 2008 3 a|EA Points of Contact International Executive Committee Korea Chapter President: John Gøtze John Kang [email protected] [email protected] Vice President: Gary Doucet New Zealand Chapter [email protected] Mike Lowe [email protected] Secretary: Kristian Hjort-Madsen [email protected] Treasurer: Scott Bernard [email protected] Standards Committee: Tyson Brooks [email protected] General Member: Richard Burk [email protected] South Africa Chapter Graham McLeod [email protected] Taiwan Chapter Cathy Sung [email protected] General Member: Mike Lowe United Kingdom Chapter [email protected] John Good [email protected] National Chapters Australia Chapter Levine Naidoo [email protected] Belgium Chapter Ingrid Evers [email protected] Canada Chapter Mike Giovinazzo [email protected] Chile Chapter Alfredo Piquer: [email protected] Colombia Chapter Francisco Ballesteros [email protected] Denmark Chapter John Gotze [email protected] German/Swiss/Austria Chapter Mike Alter United States - Local Chapters Atlanta Chapter Andrew LeBlanc [email protected] Dallas / Fort Worth Chapter William Krauter [email protected] Delaware Valley Chapter Michael Robison [email protected] California Chapter Walter Wilson [email protected] New York Chapter Brian Clark [email protected] San Antonio Chapter Orvis Meador [email protected] Seattle Chapter [email protected] Marci Hadnot [email protected] India Chapter Tampa Chapter Sunil Dutt Jha [email protected] Liesel Muth [email protected] Ireland Chapter Washington DC Metro Chapter Joe McGouran [email protected] Haiping Luo [email protected] 4 © Journal of Enterprise Architecture – November 2008 Architect’s Spotlight Waylon Krush Waylon Krush is the co-founder and CEO of Lunarline, Inc., an IT security consulting firm that is based in the Washington DC area. As CEO, Waylon manages Lunarline's overall business strategy. He has over ten years of excellence in Critical Infrastructure Protection, Information Operations, Signals Intelligence, System and Telecommunication exploitation, and Certification and Accreditation. Prior to becoming the CEO of Lunarline, Waylon was a Senior Information Security Engineer in AT&T's Advanced Systems Division, and also served as the Chief of the Information Assurance Group for GRC-TSC. He served seven years in the United States Army in various intelligence and securityrelated technical and leadership roles throughout the world. Waylon holds a BS in Computer Information Science from University of Maryland University College, and is a Certified Information Systems Security Professional (CISSP) and Certified Information Security Auditor (CISA). He is also a recipient of the Knowlton Award, United States Marine Corp Scholastic Leadership Award, Air Force Advanced Signals Award, 718th Soldier of the Year, National Security Agency’s Professional of the Quarter, Voice of America Award, and American Legion Award (2 years). JEA: Describe how you became involved with IT Security Architecture (ITSA). Krush: Early on in my career I developed systems for the Department of Defense. Although most of the networks I worked on were closed, the threat and compliance environment was changing very quickly and I was asked to develop a "secure system with a secure architecture". At first I was fairly offended, as I had a pretty strong understanding of Information Assurance (IA) and I thought I had always been performing my due diligence when it came to applying the right controls in the right area based on threat. Then I started reading more and more about the different types of requirements and found out first hand why they were so important - but that is a whole different story. Since then, I have been lucky enough to work with a few of the thought leaders in EA and Security - Dr. Scott Bernard and Dr. Ron Ross on the re-writing of the Federal Enterprise Architecture’s Security and Privacy Profile (FEASPP). JEA: How do you address the integration of enterprise architecture and IT security architecture? Krush: Today, it is simply reckless to not understand how to integrate IT security architecture into the EA. I know that sounds strong, but most organizations are very reliant on their architects to provide an architecture that will meet their performance and business needs. Well, if you plan on meeting the business need of an organization, you had better find out what compliance and security controls are required based on the organizations business environment. The best way to integrate the EA and IT architecture is first find out what type of information is going to be created, stored, processed, transmitted or managed with the system or process. Next, based on your compliance environment (C&A, HIPAA, SOX, etc.) you will select controls that meet the compliance requirements while selecting specific controls to integrate based on the organizational threat environment. JEA: What is the greatest challenge facing Enterprise Architecture today? Krush: I would say the re-tooling the information security professionals to understand EA, and vice versa. This will take a definite culture and training change to be successful. JEA: What is the greatest challenge facing IT Security Architecture today? Krush: Consistency. No one has been able to develop a widely adopted process for ensuring systems are developed with the security baked in. Of course, there are some areas in Government and the commercial worlds that are currently trying, but of course both processes and related methods are different. © Journal of Enterprise Architecture – November 2008 5 JEA: What was your most favorite architecture experience? of their architecture - just wanted to go through a paper exercise. Krush: Working on the FEA-SPP Working Group. I also have loved redeveloping the architectures of medical and embedded devices for various organizations to meet compliance and security requirements. JEA: What would you say to someone considering making security or enterprise architecture as their career field? JEA: What was your least favorite architecture experience? Krush: I will not name the customer, but they simply wanted to meet the Governments reporting requirements and nothing else. So they were not really considering security as part Krush: Take courses in business, IT, computer science, and information security. Your formal education should have a strong business and IT / engineering overview - then when you finish continue to train. EA and ITSA changes all the time, and if you do not continue to develop multiple skills you will become obsolete, just like the EA and ITSA you developed a few years ago. If you choose the field, you will find it is intellectually challenging, yet very rewarding. Call for Papers The Journal of Enterprise Architecture is accepting article submissions for its 2009 issues Research and best practice articles are sought on EA-related topics, including: Case Studies, Configuration Management, Culture, Documentation, Evaluation, Frameworks, Governance, Implementation, Maintenance, Methodologies, Taxonomies, Theory, Training, Tools, Use, Value Issue February May August November Due Date November 1 February 1 May 1 August 1 Send articles to the JEA Editor at [email protected] Author submission guidelines can be found on the a|EA website at www.aeajournal.org © Journal of Enterprise Architecture – November 2008 6 Architect’s Toolbox David Rice Review of Metastorm ProVision® Series 6 The good thing about writing a column reviewing EA tools is that one never runs out of candidates to review, at least not as long as Enterprise Architecture itself is being practiced widely. It is important to keep in mind that few tools we have reviewed to date in this column or will likely review in the future were developed since the inception of wider acceptance of EA as a viable and important part of business planning and management. Most tools in this space previously existed to fit some other need or market and were repackaged and/or modified to fit the needs the vendor perceived the EA practitioners needing and that fit the tools pre-existing capabilities. It is what vendors do because it makes business sense and I dare not pass judgment on the practice having participated in it myself previously in my career. For the EA practitioners it is important, when choosing a tool or toolset, to know what to expect from the vendor and their tools based on just where the vendor is coming from and how well their approach and perspective fits the needs of the EA program. Tool Overview Metastorm’s ProVision is exactly the sort of tool I describe above. It is a leading tool for Business Process Modeling for the purposes of Business Process Reengineering (BPR), Business Process Improvement (BPI) and Business Process Management (BPM). It is a very strong tool in this space being both easy to use and replete with powerful features for understanding and describing the strategy of the business and the processes that deliver on that strategy. Add to it the additional tools from Metastorm for Analysis and Execution and you have a powerful toolset for process driven enterprise management that Metastorm calls Metastorm Enterprise™. But does a very good Business Process tool make a good EA tool? In the previous “Architect’s Toolbox” Ian made case for why process modeling is an important part of EA © Journal of Enterprise Architecture – November 2008 and I will not repeat that wisdom. However, understanding and improving processes are not the only part of an effective EA effort, after all, if a key goal of EA is to align business and Information Technology one must understand and manage both. Metastorm understands this and their ProVision product leverages the capabilities and technology that give it such a strong presence in process modeling to also provide the capability to model, analyze and manage other aspects of the enterprise, but is it enough to really be an “End to End Solution for Enterprise Architecture” as they claim on their web site? Installation and Stability Installation: Installation of ProVision is as easy as any desktop tool – probably easier than many. It installed with no problem onto an XP machine with 2GB of RAM and with the Norton Security features still active – an important note as I am sure many of you are aware. Stability: Many years ago I started my software development career as a software tester, I suppose old habits never die because I still try to do things the programmers intended to see if those work and also do things that they did not intend but that people might do anyway. That said, in my time evaluating ProVision I had no system failures or unexpected behavior. Capability and Use Overall it is quick and easy to build architecture models in ProVision. I found the user interface intuitive and the resulting diagrams were easy to look at look at and expressive of the content. ProVision has managed a nearly perfect balance between “Drawing Tool” and “Architecture Tool”. There are a few challenges though I was caught by on my way though the learning curve; for instance, the difference between “Delete” and “Exclude” (exclude being a better choice in most cases in real life). When one does “exclude” an item the line connections to and from it are removed as well (nice) however I found that “undo” does not add back to the diagram the excluded item and all the connections. This 7 could be problematic in a large, fluid architecture effort. One other cautionary note here is for you keyboard oriented folks like myself, the delete key is “Delete” not “Exclude”, fortunately any command such as delete includes a rather detailed report of precisely what affect the action you just initiated is going to have – read the dialogs, they are helpful. One architecture item type nearly everyone is interested in is “System” – we all have them and we want to catalog them and their use, capabilities, and many other attributes of interest. A few observations about this basic architecture element in ProVision that carry on to all other types: Practically every conceivable relationship between any other artifact type and the System artifact type is handled “out of the box” as you can partly see in the dialog below. Importantly, this includes the nature of the relationship as well (in parenthesis after the artifact type listed) – this is just plain brilliant. Additionally, if one needs additional text, numeric, Boolean, etc. attributes describing a System (and you will – it would be the first extension of the tool I would do on a client engagement) making changes to attributes and relationships is easy via a dialog interface – no cryptic vendor proprietary language to deal with. In fact, there is an easy dialog driven © Journal of Enterprise Architecture – November 2008 mechanism for changing just about everything in the tool to fit the needs of your EA program – I have yet to encounter a tool that has such a clear and easy to use mechanism to allow the end user to perform these modifications. Those who have used tools that forced you to collect important data points in large text fields because they either did not provide for extension or it has to be done by some tool expert will appreciate this capability in the tool. I however have not had enough experience with the tool in this test to tell you the long term affects when you try to share data from ProVision installs that have been customized differently. Besides general ease of use and completeness of coverage of the modeling needs one will have in EA, another thing I look at is applicability of a product to large EA programs. My clients work with hundreds if not thousands of artifacts, it is therefore critical we have ways of searching artifacts and multi-selecting – and just seeing what we have. Unfortunately I some of the UI elements of ProVision would make this difficult. As an easy example, the dialog above is not resizable, so seeing long lists is difficult. Additionally, the search within a list works well enough for typing the first few characters and getting you to where you want to be in the list, however many architecture efforts are done in places where the first few characters are classification markings so this makes searching problematic. Some sort of wildcard search as part of this dialog would help, as would making the dialog resizable. Another area where there may be challenges for large programs is in relating large numbers of 8 artifacts. In the dialog above my intention was to “multi-select and add” the items in the list but only the top and bottom item were added to the right side. Might seem like a small issue but with very large datasets this is again potentially problematic. Types of Models Supported The list of supported model types is too long to list here and can be found on the Metastorm web site at: http://www.metastorm.com/products/EAM.asp The necessary subject areas for EA are well covered: Strategy, Organization, Process, Information, Communication and Technology. It is easy to see why, with all this coverage, ProVision could be customized to support nearly any EA framework (such as DODAF, MODAF, etc) without needing to invent entirely new areas of the tool. Simulation and Analysis One morning when working on this review I decided to test the simulation part of the tool, as well as the UI for defining it. I set my coffee to brewing and sat down to build a “making coffee” process model, complete with simulation parameters and to see a) how long that took, b) if it worked and c) if it gave believable results. By the time the coffee had brewed and my first cup was consumed I had completed the model and run it. The results: a very nice looking model that worked well within the realm of expectations. The simulation capability of ProVision is not “manufacturing floor” design level of detail. Very detailed simulation with lots of variants and complex mathematical expressions to define their behavior will need to be done in other tools – however, for most workflow processes the simulator will work well giving you results that at the very least will quickly lead you to the areas of the process that need improvement. Other report types include custom reports that use Crystal Reports; navigation reports that aid in traveling the relationships of architecture artifacts in the tool; reports that produce simulation graphs like cost and resource usage; and many more. ProVision’s Publishing feature helps to manage all the reports and the packaging of them for printing. I find this feature very helpful. Import/Export The list of import and export formats supported is impressive. Perhaps one of the most practically useful of all of them is the “Translator” which is a wizard driven capability to import tabular data from sources such as Excel or Word. The supported Interface formats are shown below in a screen shot from ProVision. All seemed to support both Export and Import (Translator takes care of Import from Excel). I was not able to test each one for this review but the most common in my experience (Excel via the translator) seemed to work well and did what I expected. Reporting There are many different report types in ProVision, probably my favorite is “interpret”. Interpret simply takes an open diagram and builds a report from it – doing a pretty good job of making the content of that diagram understandable by the common human. The report is customizable with the “Interpretation Options”. This is probably the easiest and quickest way to get some basic information printed about a model. © Journal of Enterprise Architecture – November 2008 9 EA Framework Support Besides being widely used in their respective spaces and therefore relevant to evaluate an EA tool against, the following frameworks also serve as a mechanism for indicating the capabilities of a tool respective to the needs EA practitioners will have conducting and EA engagement. Zachman Framework for Enterprise Architecture Tool vendors in the EA space generally claim support for the Zachman Framework and Metastorm is no exception. It is an easy enough claim to make given that John Zachman did not define any specific work products to use to fulfill the goals of his framework but rather addresses the more important issue of what to understand in order to manage and change and enterprise and how to categorize that knowledge by question (columns) and perspective (rows) so you would know what enterprise knowledge you have that is applicable to a particular issue (e.g., is the artist rendering of the building or the wiring diagram the proper level of information given the problem to be solved). If one interprets the Zachman Framework as Rows 1 and 2 being the domain of “business” or “operations” and Rows 3, 4 and 5 as the domain of the implementers of the plans, goals and strategies of the business then ProVision fits neatly in Row 1 and Row 2 with a slight incursion into Row 3. ProVision is not a software design and code generation tool, nor a System Engineering tool. Its strength is in the areas of strategy and business process modeling. Department of Defense Architecture Framework (DoDAF) The DoDAF in its present version (1.5 as of this writing) divides EA Artifacts into 4 categories: All View, Operational View, System/Service View and Technology View. ProVision is a clear fit for the Operational Views and supports them well. Provision has a unique and very detailed perspective on the All Views, providing seven different diagrams that all share the AV-1 label. © Journal of Enterprise Architecture – November 2008 Though ProVision indicates support for DoDAF there are a few important observations with any vendor making this claim: 1. The DoDAF specification presents example work products but falls short of mandating any particular modeling methods be used, so vendors and users can (and do) get creative and liberal I their interpretation. 2. The only real test (currently) of DoDAF compliance is the capability to produce the model data in file that is in a Core Architecture Data Model (CADM) conformant format. Provision was, until recently, the only COTS tool that did this in any meaningful way via CADM XML. 3. DoDAF 2.0 appears to change the landscape and requirements for tool vendors and practitioners alike. When choosing a tool for DoDAF you should also consider the vendors history of implementing new requirements of the framework and the likelihood this can continue in the future given the tool’s architecture. On the former point, Metastorm has a very good history, being first to have CADM XML Support. ProVision “double-dips” much of its support for DoDAF providing a single diagram type that is intended to support the requirements of both the Operational and System Views, for example the OV-5/SV-4 Activity/Function Modeler. There is nothing in the DoDAF specification to prevent this, if anything it is encouraged, and this approach works fine for some architecture efforts and would hinder others – largely depending if the architecture is a “Build To” vs. an “Enterprise” or “Acquisition” architecture. 10 Given the positioning of ProVision in the above EA Frameworks the claim of “End to End Solution for Enterprise Architecture” seems a bit hard to defend but keep in mind, few if any tools cover all capability needed for a complete EA solution. We have made the case previously in this column that a compete EA tool is really a toolset, probably from multiple vendors. Of course any statement about EA or its toolsets and approaches presumes all parties share a common definition of “Enterprise” and “Architecture” which is unlikely. Customizability In addition to the ability to modify the data storage and relationships of the models used (change the meta-model of the product) as mentioned previously in the example of “System”, Provision makes it quite easy to change the UI of the product itself – giving the user the ability to have the most frequently used tool capability in places most obvious to the user. A user will want to spend a bit of time with this customization because according to ProVision’s documentation, some capabilities are available from tool bar buttons and not in the menus. Another area I look at when accessing a product is extensibility of its features and functions. This usually takes shape as some sort of macro language such as Visual Basic for Applications as is present in the Office tools and many other products. ProVision does not have a built-in macro language. They do have an API but its use requires the extension of the product externally using a programming language and IDE, making if far less likely an architect would be able to extend the tool to support their needs themselves and without additional purchase of a programming environment and a programmer Conclusion For those organizations needing a process driven approach to EA, specifically geared to driving the EA from the top down and wishing to © Journal of Enterprise Architecture – November 2008 automate and optimize human and humanmachine processes, using workflow technology to the extent possible, the Metastorm Enterprise toolset should be on you’re your short list and the ProVision Product is a good place to start. If however you tend to drive change in the enterprise from the technology side and you have been looking at this column hoping for a UML tool review (coming up soon!), this is not likely the tool for you, though certainly I would encourage you to understand and optimize the business processes into which you will insert the technology and Provision will do a far better job at this than a typical UML tool. Quick Scorecard: (0-4) 4 3 3 3 4 4 4 3 3 4 2 3 40 Overall Ease of Use Coverage of EA Modeling Needs Adherence to Model Standards Automation of Model Build/Edit Appearance and Readability of Models Use of Model Data Internally Use of Model Data Externally (interfaces) Reports Included Reporting Writing Capability Stability Use on a Large EA Program Customizability Total (out of 48) 0=no applicability; 1=Poor; 2=Fair; 3=Good; 4=Excellent System Requirements According to Metastorm, ProVision has the following system requirements: Microsoft Windows 2000, XP, and Vista Minimum of 512 MB RAM, Pentium 4, 2.0+ GHZ , 120 MB hard drive space . At least 100 MB to 200 MB storage dedicated to projects (depends on the size of your project data). About Metastorm Information about Provision can be found at: http://www.metastorm.com/products/mpea.asp For more on this or other EA tools, you can contact David at [email protected] 11 Book Reviews Editor’s Note. This is the first time that the Journal of Enterprise Architecture has included reviews of books and e-books on enterprise architecture and related topics. As editor, it is my intention to include additional reviews in future issues of JEA, as relevant new books are published and existing books are updated. I welcome reader suggestions of books that we should include in future reviews. These reviews are intended to provide a factual summary of what is in the book, and not stray into opinion or ratings – I leave that to the reader – and there are a number of sources to get that type of information from on each book. We present the books in the order of the year they were published – oldest first. The titles that we cover in this issue are as follows: 1992: Steven H. Spewak, with Steven C. Hill Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology 2004: Jaap Schekkerman How to Survive in the Jungle of Enterprise Architecture Frameworks 1994: Henry Mintzberg The Rise and Fall of Strategic Planning 2005: Scott A. Bernard An Introduction to Enterprise Architecture: EA3 Linking Business and Technology (2nd Edition) 1996: Melissa Cook Building Enterprise Information Architectures: Reengineering Information Systems 1999: Bernard H. Boar Constructing Blueprints for Enterprise IT Architectures 1999: Joseph Morabito, Ira Sack, and Anilkumar Bhate Organization Modeling: Innovative Architectures for the 21st Century 2001: Jan Killmeyer Tudor Information Security Architecture: An Integrated Approach to Security in the Organization 2002: Ivan Margoius Architects + Engineers = Structures 2003: Peter Bernus et al. Handbook on Enterprise Architecture 2003: James McGovern et al. The Practical Guide to Enterprise Architecture 2003: Col Perks and Tony Beveridge Guide to Enterprise IT Architecture 2003: John A. Zachman Zachman Framework for Enterprise Architecture © Journal of Enterprise Architecture – November 2008 2005: Marc Lankhorst et al. Enterprise Architecture at Work: Modelling, Communication and Analysis 2005: Fenix Theuerkorn Lightweight Enterprise Architectures 2006: Adrian Grigoriu An Enterprise Architecture Development Framework: The Business Case, Best Practices and Strategic Planning for Building Your Enterprise Architecture 2006: Eric A. Marks and Michael Bell Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology 2006: Jeanne Ross, Peter Weill, and David Robertson Enterprise Architecture as Strategy: Creating a Foundation for Business Execution 2007: Edited by Pallab Saha Handbook of Enterprise Systems Architecture in Practice 2009: Edited by Gary Doucet, John Gotze, Pallab Saha, and Scott Bernard Coherency Management: Architecting the Enterprise for Alignment, Assurance, and Agility 12 Book Review Enterprise Architecture Planning Developing a Blueprint for Data, Applications and Technology by Steven H. Spewak with Steven C. Hill 1992: John Wiley & Sons, Inc. ISBN-0-471-599859 392 Pages This book on Enterprise Architecture Planning by Steven Spewak is a classic in the EA community. It was published in 1992, which is the same year that John Zachman published the second of his two seminar articles on an information systems architecture (later renamed as an enterprise architecture framework). The book’s Foreword is written by John Zachman, and aligns with much of Zachman’s thinking, yet achieves a number of firsts, including; the first book to use ‘Enterprise Architecture’ in its title; the first book to provide an EA methodology; the first book to provide an EA non-matrix model of an EA framework (the ‘wedding cake’ multi-level model); the first EA approach to specify that current and future views of the architecture should be developed, along with a transition plan. Many of the concepts in this book remain relevant and implementable. It is an excellent resource for the first time practitioner; this book provides a detailed description of each phase of the enterprise architecture process and serves as an actionable resource for any organization embarking upon the enterprise architecture journey. The author argues that determining how to set the stage for enterprise architecture adoption is as fundamental a step as choosing the framework to follow. Presenting a seven step process that starts with developing an initiation plan, each step is discussed down through the development of a preliminary business model, an inventory of current systems and technology architecture, a data architecture, an applications architecture, a technology architecture and an implementation plan. The author provides ample examples and associated deliverables throughout each step. Also providing functional scenarios, sample interview surveys, a presentation outline, and a five step process to data and application architecture, the author presents enough detail to be executed without much further exploration. The author utilizes the Zachman Framework as a reference to planning enterprise architecture and states that the development of an enterprise architecture plan is inclusive of Zachman’s “ball park view” and “owner’s view.” Recognizing that the concepts drive the plan and require an understanding of the framework, the author presents a depiction of how the Zachman framework applies to enterprise architecture planning (e.g., the “owner’s view” is applied in the applications architecture phase and the “ball park view” is applied in the technology architecture phase). Discussions on the implementation plan, final report and transition plan are the concluding chapters of this book. Outlining the four step process to creating an implementation plan, the author stresses that the development of the implementation plan is the activity most relevant to the business. Readers will find the appendix rich with sample business case formats, functional data models, a list of EAP products and consulting companies specializing in enterprise architecture. © Journal of Enterprise Architecture – November 2008 13 Book Review The Rise and Fall of Strategic Planning by Henry Mintzberg 1994: Simon and Schuster ISBN 13--9780029216057 458 Pages This book was included in JEA’s Book Review because the strategic dimension of EA is emerging as an important element of current theory and practice. A modern classic among strategic planners, this book by noted management theorist Henry Mintzberg provides deep insight into the history of the strategic planning discipline, its performance to date, shortcomings and ways strategic planners can overcome the obstacles discussed. Written in a conversational manner, the author begins with a historical analysis of what planning has been, what it has come to be and why it is still necessary. Using the same simplistic, conversational writing style, a deep review and assessment of the strategic planning process is presented. Reviewing the various planning models, four planning hierarchies and the different forms of strategic planning, Chapter 2 marks the end of the “background” information and the discussion about the “rise of strategic planning”. Just prior to revealing the historical shortcomings of strategic planning, the author presents a thorough review of the “evidence” of strategic planning’s performance. Using a combination of personal insight, statistics and case studies, the author makes clear that “something has indeed gone wrong” within the discipline of strategic planning and reveals how strategic planners up to that point have responded to that reality. This chapter (i.e., Chapter 3) marks the beginning of “the fall of strategic planning”. Two chapters (Chapter 4 and Chapter 5) are dedicated to unveiling specific pitfalls and fundamental fallacies of the strategic planning discipline. The final chapter (Chapter 6) is dedicated to addressing the roles planning, plans and planners can play in organizations while also putting the planner role within context. Addressing the specific pitfalls of strategic planning, Chapter 4 boils all of the pitfalls discussed down to an issue of “an obsession with control.” Chapter 5, on the other hand, discusses the fundamental fallacies of (1) predetermination, (2) detachment, and (3) formalization – all of which the author says points to how the term “strategic planning” is an oxymoron. The author argues that strategy cannot be planned because planning is about analysis and strategy is about synthesis. Admittedly in Chapter 6, the author changes his tone from one critical of the strategic planning process to one of constructive application providing practical suggestions for how organizations can effectively employ planning, plans and planners. A statement in the author’s conclusion best states the overarching message of this book despite the enormous background information and insightful research and analysis presented: “Planning has an important role to play in organizations, as do plans and planners, when matched with the appropriate contexts.” © Journal of Enterprise Architecture – November 2008 14 Book Review Building Enterprise Information Architectures Reengineering Information Systems by Melissa Cook 1996: Prentice Hall PTR ISBN-10-0134402561 224 Pages This book is one of the earliest that was written on enterprise architecture - related topics. John Zachman wrote the Foreword to the book four years after completing his own approach, which provides an interesting context for the information systems architecture concepts that Melissa Cook articulates The book provides a practical introduction to enterprise architecture for business managers and information technology professionals alike. With an ultimate goal to help readers create alignment between information technology and business, the book describes the origins of architecture, the challenges faced when architecture is absent, and how information technology architecture best practices can be applied to solve modern business challenges. Early on, the author presents an assessment of the state of information architecture. Asserting that the root of most systems challenges is a lack of dialog from and investment by the lines of business in information technology endeavors, the author presents cautionary tales to reinforce the dilemmas many organizations face in information technology architecture. The author argues that despite the major advances in information technology, business managers still struggle to balance the benefits of conformity in strong standards against the will to remain independent and nimble. The book propels the reader through a historical view of "why" (to do information architecture) to the practical view of "how" (to do information architecture) presenting crisp definitions of the rudiments of information architecture (i.e., classification, composition, and the relationships inherent in information architecture). The author makes a case for organizations allowing business to serve as the guiding force for building information systems. The author states that utilizing the Zachman Framework helps organizations align business process and data architecture. The author suggests that classifying data and processes into a working framework (such as the Zachman Framework) facilitates a “ballpark view” of the enterprise while also providing a business “owner’s view” which is vital to an organization. The book concludes with a three step process to implementing architecture. Reinforcing the message of a top-down approach for addressing architecture, the book advises the reader to begin reengineering with an inventory of what currently exists and then identifying both the interim and future views. The book contains many concepts on information systems architecture that are still relevant today, and provides an interesting perspective on the initial period of enterprise architecture practices. © Journal of Enterprise Architecture – November 2008 15 Book Review Constructing Blueprints for Enterprise IT Architectures by Bernard H. Boar 1999: John Wiley & Sons ISBN 0-471-29620-1 352 Pages Written during the telecommunications boom, this book provides a formal notational system for developing and maintaining IT architectures (referred to by the author as Enterprise Information Technology Architecture Blueprinting or EAB). Intended to define a communications system that allows IT professionals to visualize architectures in a standard manner, EAB is defined by the author as “a rigorously structured document divided into sections and subsections.” Specifically, an EAB represents a template of sorts for developing an IT architecture blueprint. Discussed within the context of the hypercompetitive telecommunications environment experienced at that time, the author argues that IT architecture is the foundation for competitive advantage and presents this case in the first chapter of the book. A detailed look at the definition of IT architecture and the need for a blueprint system is presented in Chapter 2 before reaching the “heart” of the book in Chapter 3 which begins the discussion about blueprinting and the EAB methodology. Providing a detailed overview of the EAB sections, diagrams and notations, Chapter 3 concludes with a set of “notions” which summarize the building blocks of an EAB. Chapter 4 discusses four types of EAB configuration management and provides insight into the implications and organizational considerations of configuration management. Addressing the EAB’s importance in architecture evaluation, the configuration management discussion is concluded with a suggestion that configuration management can serve as a strategy within a hypercompetitive environment. In Chapter 5, the author discusses how organizations can maximize the adaptability of IT assets through a combination of blueprinting, configuration management and a focused effort on designing for maneuverability. Adding to earlier discussions about blueprinting and configuration management, this chapter presents a specific way to design IT such that the highest level of adaptability results. The book’s final chapter, “EAB Miscellany” discusses a number of non-technical, EAB implementation topics that will be helpful to an organization seeking to implement the methodology. These topics include cost justification, implementation planning, commitment planning and a set of frequently asked questions. In support of material covered earlier in the book, the Appendices conclude the book by providing actionable EAB templates and guidelines for architecture principle development. © Journal of Enterprise Architecture – November 2008 16 Book Review Organization Modeling Innovative Architectures for the 21st Century By Joseph Morabito, Ira Sack, and Anilkumar Bhate 1999: Prentice Hall PTR ISBN-0-13-257552-3 300 Pages This book is offered as a companion to advanced coursework in organization modeling. Academically written, readers will find a structure for organization and information modeling. The authors state that organizational theory is the best forum for organization modeling since it is evidence-based and its constructs are unchanging. The modeling paradigm is founded on organization theory which is broken down into core organization constructs and derivative management philosophies. Strongly rooted in organization theory, the book’s goal is to provide a disciplined approach to develop and change organizational architecture. The book introduces the idea of ‘object-oriented organizational modeling’ and discusses the following concepts: why it's dangerous to think of today's IT models as "business models"; how to create and align small-scale "organization molecules" into effective enterprise-wide architectures; envisioning organizational patterns; and integrating data, knowledge, and information. The authors build their argument using two premises. The first premise asserts that the heart of a solid structure is firmly grounded in organizational theory. The core constructs in said organization theory are as follows: environment, power, strategy, process, information, human, structure, and tool. Learning and culture management philosophies are derived from these essential core constructs. The second premise posits that behavior defines the boundaries and interplays with organizational constructs. The author explores the three views of modeling using this concept as the basis. Borrowing from molecular biology, descriptions of atomic and molecular structures are presented as analogies for decomposing, classifying, and organizing constituent personnel, assets, goals and folkways critical to a successful modeling process. The authors suggest that observed rules-based patterns in nature make an excellent foundation for describing similar behaviors and approaches to managing business and technology. The authors build the case for the primacy of organizational modeling theory by detailing a broad variety of classification schemas, alignment patterns, refinement models, and a complete list of useful components to be considered. Individual and organizational values in data and knowledge are thoroughly explored. The nature of decision making, both centralized and decentralized, is decomposed and catalogued. The final passages in this book reveal the author’s belief in an organizational modeling evolution toward 21st century business design. The result sought is a highly evolved model-driven environment existing as both a single organism and a collection of a well-integrated colony of processes. © Journal of Enterprise Architecture – November 2008 17 Book Review Information Security Architecture An Integrated Approach to Security in the Organization by Jan Killmeyer Tudor 2001: CRC Press LLC ISBN-0-8493-9988-2 424 Pages This book is a beginner’s reference to information security architecture and strategic-level security planning. The book describes the process to implement an information security project. Written for the novice security analyst, the author presents a framework for completing a security plan. The book has may detailed examples for completing a security plan and information security architecture. The author provides sample guidelines, procedures and forms which serve as the templates to reduce implementation guess work and risk. The author presents an information security methodology as the context for discussing the spectrum of organizational vulnerabilities. The analogy of securing a residence simplifies the details, plans of business models, organization architecture, measurement tools and technology applied to the problem. In the discussion, the author stresses the value of consensus and ownership. Reference cases serve to bolster the argument that without buy-in from the lines of business better results in information security cannot be achieved. The author follows the premise that a security plan involves all levels of the enterprise and calls for an integrated plan that is comprised of five components (i.e., security organization and infrastructure, security policies, standards and procedure, security baselines and risk assessments, security awareness and training programs and compliance). The author deems these components as interrelated and discusses them within the context of their relationship to each other. The book’s concluding chapters address the barriers to a successful initiative. The author addresses implementation roadblocks in detail and demonstrates how to examine a plan’s foundation for soundness. Stating that the core of the examination is to follow a five point component checklist, derailment factors are also explored. The derailment factors discussed include scarcity of resources, traps in perpetual technology updates and the disruptive impact of mergers and acquisitions. The author explains that the best plans for information security anticipate inevitable challenges. The appendix provides a host of sample security policies, sample security assessment work plans and sample compliance plans. Understanding that a security plan exists to reduce security risk and to prevent, control and manage intrusions, an effective framework upon which to operate an information security architecture is also important. © Journal of Enterprise Architecture – November 2008 18 Book Review Architects + Engineers = Structures by Ivan Margoius 2002: Wiley-Academy, Chichester, West Sussex ISBN: 0-471-49825-4 104 Pages This book is included in the JEA Book Review to provide a reference on how “traditional” architects (who design homes, buildings, etc.) think about the relationship between architects and engineers – and why this relationship is important. In many ways, this discussion parallels those in the field of enterprise architecture (EA) that address the relationship between enterprise architects and technologists – which has evolved as a result of the field of EA moving beyond information technology, to now include business and strategy dimensions. The book studies the value of collaboration between architects and engineers. The book begins with an exploration of structure in nature and then progresses to a discussion about how the value in thoughtful design and spare use of materials evolved builders into designers. The author then goes on to explain that designers then evolved into architects and engineers as two separate disciplines. Combining the teams of architects and engineers, the author talks about how the opposing disciplines came together to create advanced works moving the entire realm of design forward. This realization forms a key message in the book. The book presents the challenges and triumphs in structural engineering over several centuries. The reader is introduced to the history of structures and those individuals credited for the great advances in the structural engineering discipline. The stories behind great designs realized spans from Brunelleschi’s domes through Frank Lloyd Wright’s use of steel to Bernard Wex’s application of new materials in modern bridge spans. Three archetypal relationships emerge from the selected vignettes: (1) the relationship of man in the natural world taking structural cues from cocoons and sea shells, (2) the relationship of skills crossing boundaries to and from the roles of architect and engineer and (3) the relationship of the architect and the engineer working together to render an artistic vision in the most efficient way. A succinct review of structural science, the book weaves human interest elements with depictions of applied theory. The lessons presented transcend the study of the design of physical structures and make clear the relevancy to the enterprise architecture discipline. The book draws to a close posing the argument that emerging new materials will further fuel the engine for advancement in engineering and architecture. The author underscores the value of collaboration as a catalyst for change. The point is made clear that top architects and engineers share common skills and experiences. These specialists may approach problems at odd angles but bridge gaps by applying well rounded approaches. © Journal of Enterprise Architecture – November 2008 19 Book Review Handbook on Enterprise Architecture By P. Bernus, L. Nemes, and G. Schmidt 2003: Springer-Verlag, Berlin ISBN 3-540-00343-6 896 Pages Designed to be a practical guide and comprehensive reference, the handbook is a collection of articles covering a range of topics related to enterprise architecture. Written for a variety of audiences, the authors identify enterprise engineers as a particular interest. The handbook is organized into five parts designed to cover various aspects of enterprise architecture (Part I: Architecture Frameworks – Organizing Enterprise Architecture Knowledge, Part II: Strategy Making and Business Planning, Part III: Defining the Requirements for Enterprise Change, Part IV: Developing the Master Plan – Architectural Design of the Changed Enterprise and Part V: Case Studies). The handbook is based on the Generalised Enterprise Reference Architecture and Methodology (GERAM). Offering an academic discussion of enterprise architecture, the first chapter of the handbook concludes with an introduction to the GERAM. Chapter 2 presents the official document for the GERAM and details the structure, components and key terminology of the methodology. The longest chapter in the handbook, Chapter 3 compares a number of enterprise architecture frameworks to the GERAM and positions the GERAM as an approach that generalizes the contributions of other frameworks such that the resulting set of tools, methods and models can be leveraged by any organization. Throughout the chapter, assessments of each of the other frameworks are presented on the basis of life cycle phases, “life history”, modeling frameworks, modeling languages, methodologies, reference models, construct and enterprise engineering tools. Part II of the handbook, transitions to the topic of strategy and business planning. Addressing topics such as leadership, capability improvement and business models, the articles are focused on business aspects influencing the development and use of enterprise architecture. Part III of the handbook addresses topics related to defining the requirements for enterprise change. With an obvious focus on modeling, the authors address a number of areas including enterprise modeling, resource requirements and the aspects of modeling function, information and management systems in. Part IV includes articles dedicated to considerations made in the development of the “changed enterprise” design while Part V concludes with four case studies that reinforce some of the key points made earlier in the handbook. © Journal of Enterprise Architecture – November 2008 20 Book Review The Practical Guide to Enterprise Architecture By James McGovern, Scott Ambler, Michael Stevens, James Linn, Vikas Sharan, and Elias Jo 2003: Prentice Hall ISBN 0-13-141275-2 306 Pages The authors state that this book is intended to “help readers create adaptive architecture strategies for successfully implementing enterprise architectures… This classic handbook goes beyond theory and presents strategies that are based on experiences within organizations across multiple industry verticals.” The book is not a compilation of submissions from contributing authors, as it covers the following subjects in a dozen coordinated and synthesized chapters: Systems Architecture, Software Architecture, Service-Oriented Architecture, Software Product Lines, Methodology Overview, Enterprise Unified Process, Agile Architecture, Agile Modeling, Presentation Tier Architecture, Usability and User Experience, Data Architecture, and Thought Leadership. The authors state that “Enterprise architecture identifies the main components of an organization and how components in the organization’s nervous system function together to achieve defined business objectives.” The authors’ state that “the book is suitable for all information technology professionals who have the passion and discipline to study technology to the level required for successful implementation.” Their intended audience includes project managers, senior developers, software architects, and enterprise architects “employed by Fortune 1000 organizations or by consulting firms that serves executives and chief information officers (CIOs), chief technology officers (CTOs), and others within the IT technology management chain.” The book does not promote or follow a particular meta-methodology, rather it provides a summary overview of various design, analysis, and modeling approaches and frameworks. This includes the Zachman Framework, Model Driven Architecture, the Capability Maturity Model, and various types of System Development Lifecycle Models. As such this book is a good companion to books on particular enterprise architecture methodologies, as it provides additional detail and alternative views on data modeling, software development, and service-oriented architecture that would be complementary. © Journal of Enterprise Architecture – November 2008 21 Book Review Guide to Enterprise IT Architecture by Col Perks and Tony Beveridge 2003: Springer-Verlag ISBN 0-387-95132-6 447 Pages This book addresses a wide range of architecture topics and issues. Following The Open Group’s Architecture Framework (TOGAF), the authors present a number of concepts, practices, case studies and examples that demonstrate the need for organizations to take a more structured approach to IT planning, analysis, design, implementation and governance. Written in a textbook format, the intended audience for this book includes individuals involved in a number of technical capacities to include technology planning, procurement, management, and consulting. Among the goals of the authors is to set apart “technical architecture” from all other forms of architecture to include information architecture, business architecture and application architecture. To this end, the book focuses on providing detailed guidance on the development of enterprise technical architectures addressing other forms of architecture only when necessary and within the context of technical architecture. Very early on, the authors make a clear distinction that technical architecture is an organizational capability and not simply a set of standards, strategy or set of documentation. Presenting typical IT challenges experienced by organizations, the authors lay the foundation for applying architectural principles to address architectural control issues. Discussion of these issues and the brief “technical architecture to the rescue” reviews appropriately set the stage for introducing TOGAF as a set of tools used to produce an IT technical architecture. Comprised of four components, the TOGAF is covered throughout the remainder of the book and said to exist within the “enterprise continuum” (which represents an evolution of architecture planning and realization). The majority of the TOGAF discussion is dedicated to presenting its architecture development method (ADM), a seven stage process for developing and maintaining an organization’s technical architecture. Interwoven between ADM chapters are relatively brief discussions on architectural views (i.e., different areas of focus) and “super services” (i.e., “services of services”). The book closes with a discussion of some of the major factors resulting in the failure of architectural initiatives and approaches that mitigate such risks. Key highlights the authors close with include stressing the need to execute IT from a defined plan based on the organization’s business plan and the use of TOGAF in tackling the technical, organizational, political and process issues associated with the development of architecture. © Journal of Enterprise Architecture – November 2008 22 eBook Review Zachman Framework for Enterprise Architecture By John A. Zachman 2003: CD - Available through www.zachmaninternational.com John A. Zachman is the widely acknowledged “Father of Enterprise Architecture.” His seminal article in 1987 and follow-on article with John Sowa in 1992 in the IBM Systems Journal were the catalyst for what has become the profession and practice of Enterprise Architecture world wide. Since these articles were published, he has published a number of white papers through his organization, and a number of articles in various publications, including the Journal of Enterprise Architecture (he contributed to the inaugural issue in August 2005 and again in February 2008). John’s chose to publish many of his articles and a comprehensive presentation of the Zachman Framework in a CD that he produced in 2003. The CD is only available on-line through www.zachmaninternational.com and promotional materials describe the contents as follows: “At over 500 pages, color jpegs and 140mgs of video, this ebook defines The Zachman Framework™ for Enterprise Architecture like no other source. Authored by John A. Zachman himself, it takes the issues of Enterprise Architecture, and the industry-standard Zachman Framework™ from mystical to practical, from methodology to ontology. If you are looking to actually "do" Enterprise Architecture, then there is no other place to start than "The Zachman Framework for Enterprise Architecture™: A Primer for Enterprise Engineering and Manufacturing. This ebook is written from the perspective of someone who already understands the value of and is already committed to the concept on Enterprise Architecture. I am not trying to convince someone that they should do Enterprise Architecture. I am defining the logic of a Framework, a Framework for Enterprise Architecture, which is an analytical tool to help one think about an extremely complex object, the modern Enterprise. Enterprises are so complex and are changing so rapidly, it would be impossible to think about them holistically without a classification scheme that enabled analysis of one variable at a time without losing sense of the Enterprise as a whole.” The intended audience (per Zachman) includes: “General Managers – for understanding and devising realistic, pragmatic, strategies to address complexity and high rates of change Enterprise Architects – for establishing authoritative logical Architectural constructs and Enterprise Engineering Design Principles and a basis for methodology and tool decisions Technology Management – for establishing a context for making Enterprise asset/expense trade-off decisions and reducing time to market for major systems implementations Technology Implementers – for establishing a rationale for design and implementation decisions and a basis for negotiating technical trade-offs.” © Journal of Enterprise Architecture – November 2008 23 Book Review How to Survive in the Jungle of Enterprise Architecture Frameworks Creating or Choosing an Enterprise Architecture Framework by Jaap Schekkerman 2004: Trafford, Victoria, Canada ISBN-1-4120-1607-x 224 Pages Written for public sector consultants, program managers, and strategists, this book unveils the founding principles of enterprise architecture which serves as the basis for the fourteen frameworks discussed. Leveraging case examples, the author addresses the applicability of enterprise architecture frameworks to organizations. For each enterprise architecture framework presented, the history, purpose, scope, principles, structure, guidance and compliance criteria are made clear. In addition to the general information provided for each framework, the author also presents the context in which each framework was developed as well as details about the laws and regulations relevant to each model. Throughout the text, the author sets out to assist readers in comparing the various frameworks and synthesizing the frameworks’ applicability to their organization. Having provided practical insight into the various frameworks, the book then helps the reader link the use of each of the frameworks to enterprise architecture tools. Highlighting the fact that practitioners must leverage tools to design and apply frameworks once chosen, the author provides a review of the distinction between the different types of enterprise architecture tools (namely enterprise architecture repositories and enterprise architecture modeling tools). Associating enterprise architecture modeling suite tools with a top-to bottom approach to enterprise architecture, the author associates repository tools with a bottom-up approach capturing existing knowledge within the tool. In the words of the author: “Several times in my Enterprise Architecture (EA) practice, people asked me which framework shall I adopt or what are the benefits of the Zachman framework over TOGAF, etc. Others asked me to help them to define their own corporate EA framework. Before answering these types of questions, it is important to know what the differences and commonalities are of these frameworks and standards. This book explains the role of Enterprise Architecture Frameworks and shows the differences between the most popular Enterprise Architecture Frameworks now a day available in the world. With the growing importance of Enterprise Architecture [EA] at the same time, the discussion started how to create or choose the right Enterprise Architecture Framework & Tools for your organization in the jungle of the existing ones. Giving an overview of the history of most Enterprise Architecture frameworks as well as their purpose, scope, principles, structure, guidance and compliance, will support you in identifying the usefulness of these Enterprise Architecture frameworks for your own situation. For the in-depth details of the described Enterprise Architecture Frameworks, references to the original sources of information are added in the chapter References & Bibliography.” (Source: Amazon.com - Editorial Review) The book concludes by providing an approach to selecting an enterprise architecture tool and demonstrating that the choice of an enterprise architecture tool is dependent on both the framework selected and the requirements of the enterprise. In this final discussion, readers are also presented with a matrix of enterprise architecture tools and vendors that outlines what products support which frameworks and whether development capabilities exist. © Journal of Enterprise Architecture – November 2008 24 Book Review An Introduction to Enterprise Architecture EA3 - Linking Business and Technology (2nd Edition) by Scott A. Bernard 2005: AuthorHouse, Bloomington, IN ISBN 1-4208-8050-0 356 Pages Written to support new coursework development in the area of enterprise architecture, this book provides a practical, layman’s overview of enterprise architecture concepts and approaches while also introducing the author’s EA3 framework. The book presents the content across four sections and thirteen chapters with each preceding chapter serving as a building block to the next. The author uses a combination of case studies and exercises to reinforce key points enabling the reader to grasp the content from multiple perspectives. Section I of the book (i.e., “The Concept of Enterprise Architecture) provides an in-depth look at the “what” and “why” of enterprise architecture. This section also highlights the organizational culture and structure considerations of enterprise architecture which appropriately serves as a precursor to addressing the development of enterprise architectures in Section II (i.e., “Developing an Enterprise Architecture”). Presented in somewhat of an instructional manner, Section II provides step-by-step guidance on how to develop an enterprise architecture giving the reader insight into some of the different frameworks and approaches available. Also in Section II, the author leverages the EA3 framework to present examples of artifacts and components typically included in current and future architectures. Sections III (i.e., “Using and Enterprise Architecture) and IV (i.e., Enterprise Architecture as a Profession) round off the book by addressing the use of enterprise architecture within organizations and future trends in the profession. Section III is dedicated to addressing the IT governance areas of investment planning, project management, IT security and enterprise architecture maintenance. Providing enough detail to provide the reader actionable insight into each of the activities, combined, these activities integrate with enterprise architecture to provide organizations with a well-rounded IT management infrastructure. Section IV closes the body of the book with an encouraging snapshot of the author’s view of the future of enterprise architecture. Touching upon topics related to new enterprise architecture standards, new enterprise architecture models, organizational integration of enterprise architecture, and enterprise architecture certification, the author discusses anticipated trends. The appendices of the book provide a plethora of resources including a template for developing an enterprise architecture business case, examples of approaches used in federal, state and defense organizations and a proposed enterprise architecture artifacts list based on the EA3 framework (with examples). © Journal of Enterprise Architecture – November 2008 25 Book Review Enterprise Architecture at Work Modelling, Communication and Analysis by Marc Lankhorst, et al. 2005: Springer-Verlag, Berlin ISBN-10 3-540-24371-2 334 Pages Written for practitioners and students, this book focuses on presenting a “language” for enterprise architecture modeling, communication and analysis. Born out of the ArchiMate project, this work has a goal to demonstrate how architectural domains can be integrated to deal with the complexity of enterprise architecture. Beginning with a range of foundational, enterprise architecture topics such as enterprise architecture methods, frameworks, business applications and business management relationships, the authors set the stage for addressing modeling, communication and analysis in enterprise architecture. Early on, the authors use discussions about organizations’ specific needs of design, communication, realization and change in enterprise architecture to reveal areas in which many traditional enterprise architecture approaches fall short. The discussion is then used as a lead-in for presenting the case for their own enterprise modeling language and approach, ArchiMate. ArchiMate is a modeling language in which service orientation plays a central role. Leveraging three dimensions of modeling, the authors purport that ArchiMate fulfills key roles of enterprise modeling providing a means for integrating enterprise architecture domains and allowing models to show structures within and between domains. Providing the basis for enterprise architecture visualization and analysis, ArchiMate guidelines for modeling, selecting and using various views as well as techniques for conducing enterprise analysis are presented in the book. Leveraging results from the “Guidelines Regarding Architecture Alignment” (GRAAL) project, the authors introduce the GRAAL Alignment Framework as one that can be used to describe “alignment phenomena” found in organizations. Consisting of four dimensions, the GRAAL Alignment Framework was leveraged to assess architecture alignment in six organizations which resulted in a number of propositions that the authors discuss in the book. The concluding chapters discuss the importance of enterprise architecture tool solutions which better integrate with one another and present three case studies focused on the concepts and techniques presented in the book. Closing with an insightful look into the world before and after enterprise architecture, the authors project that enterprise architecture is here to stay and will be extended to encompass the “business network” versus simply the “enterprise”. © Journal of Enterprise Architecture – November 2008 26 Book Review Lightweight Enterprise Architectures by Fenix Theuerkorn 2005: CRC Press, FL ISBN 0-8493-2114-X 274 Pages The intent of this book is to present an architectural approach that enables a quick alignment of technology and business strategy and that reaches a wide enterprise audience. Clearly stated, the author identifies five key benefits for readers (1) a simple and easily executed enterprise architecture approach, (2) the ability to embrace a complex environment, (3) a framework to measure and control technology at the enterprise level, (4) a sense of purpose for architecture activities and (5) a reference guide for developing and maintaining enterprise architectures. Noting that the successful adoption of enterprise architecture within an organization requires the participation of many stakeholders, the author created the Lightweight Enterprise Architecture (LEA) approach to reach a wide range of audiences within an organization. Consequently, the audience for this book includes a combination of technical practitioners and business managers. Early in the discussion, the author offers that the value of an enterprise architecture methodology is in developing a clear, systematic approach that delivers the right balance between tools and techniques. LEA is presented as an approach that will deliver that value as an easily executable and streamlined option. LEA offers a simple set of artifacts to address organizations’ enterprise architecture. The book is organized into four sections. The first section (i.e., “State of Architecture”) provides a background discussion on the history, “many faces”, need and benefits of enterprise architecture. Throughout the first section, the reader is briefed on how enterprise architecture is currently utilized and continues to evolve concluding by introducing the LEA framework. The second and third sections of the book (i.e., “Framework for LEA” and “Implementing LEA” respectfully) provide specific details about LEA’s structure and implementation considerations. Offering a number of LEA implementation “helps”, the author also shares the potential challenges and types of “dysfunctional behavior” faced when leveraging the LEA model. The book concludes with the fourth section (i.e., “Appendices”) providing a summary of LEA artifacts and Open Applications Group Integration Specification references. © Journal of Enterprise Architecture – November 2008 27 Book Review An Enterprise Architecture Development Framework The Business Case, Best Practices and Strategic Planning for Building Your Enterprise Architecture by Adrian Grigoriu 2006: Trafford Publishing ISBN 1-412086663 232 Pages According to the author, the book was written to describe “a unifying view of many related Enterprise Architecture (EA) technologies: Business Process Management (BPM), Technology Architecture, IT Application Integration Architecture (EAI), Information Architecture and Service Oriented Architecture (SOA).” Other areas described in the book include enterprise strategy specification in alignment to the Technology Architecture, and the drivers and benefits of Enterprise Architecture. The author also discusses how to build a business case for an EA, introduces a formula for determining a Return on Investment for EA (RoEA), and calculates the payback and net present value financial indications for EA. “The book was written in an attempt to answer some of the common sense business questions related to Enterprise Architecture. What are the issues? What is Enterprise Architecture? Why should an organization consider Enterprise Architecture? And how to build the Enterprise Architecture. An innovative Enterprise Architecture Framework is proposed. The framework looks like a content page showing the chapters of a book or in this case the components of the Enterprise Architecture without actually describing them but showing how they fit into the whole. The book then identifies and summarizes Best Practices in the Enterprise Architecture development. Practices will be outlined at each phase of a proposed Enterprise Architecture building process which in itself becomes a suggested good practice. The book is intended to be a document essentially summarising why and how to build an Enterprise Architecture.” (Source: Amazon.com). The book is published as a paperback, and according to the author, the intended audience is wideranging and includes CEOs, CTOs, Enterprise Architects, business analysts, IT architects, employees, and all enterprise stakeholders “for understanding how the framework exhibits views satisfying their concerns.” © Journal of Enterprise Architecture – November 2008 28 Book Review Service-Oriented Architecture A Planning and Implementation Guide for Business and Technology by Eric A. Marks & Michael Bell 2006: John Wiley & Sons ISBN-13-9780471768944 384 Pages The goal of this book is to serve as a “field guide” for business and IT executives in understanding service-oriented architecture (SOA) as a concept, how SOA is implemented as well as the organizational and cultural issues associated with SOA. Spoken in clear and certain terms, the authors begin with an introduction to SOA describing what SOA is (and is not), building the case for why organizations should pursue SOA while also presenting some of the challenges organizations face in pursuing SOA. Leveraging a business case example, the authors reinforce SOA’s focus on business services making clear that SOA is not solely about information technology. Dedicating an entire chapter to explaining, in depth, the definition, purpose, characteristics, use and lifecycle of services, the authors seek to ensure that readers understand the concept of services and their relationship to SOA early on as the remaining discussions build upon a solid grasp of these concepts. Turning to a focus on SOA business modeling, the authors provide practical guidance on how to approach SOA business modeling which is defined as “the process by which an SOA initiative is pursued within the business and strategic context of an organization”. The book makes clear that SOA is realized over time through iterations, and introduces four types of iterations that are based on the SOA Business Iteration Model introduced in Chapter 3. Returning the focus to services, Chapter 4 begins a three chapter probe into the implementation of SOA services. Enveloped by explanations of key topics within each of the SOA service implementation activities, the authors provide a combination of how-to guidance and best practices on identifying, analyzing, designing, integrating and reusing SOA services. The final three chapters of the book (Chapters 7, 8 and 9) address, primarily, the organizational and enterprise architecture considerations that must be made when embarking upon the development and maintenance of a SOA environment. Chapter 7 addresses SOA governance, organization and behavior while Chapters 8 and 9 focus on the enterprise architecture implications of SOA and the value SOA brings to an organization respectively. © Journal of Enterprise Architecture – November 2008 29 Book Review Enterprise Architecture as Strategy Creating a Foundation for Business Execution by Jeanne Ross, Peter Weill, and David Robertson 2006: Trafford Publishing ISBN 1-412086663 232 Pages This book achieved a breakthrough in the enterprise architecture (EA) community by solidifying the message that EA is now about much more than information technology (IT), it is about business processes and business success, and that EA should be viewed as part of a strategy that creates a foundation for execution that manages changes in operations and how IT is utilized, one project at a time. According to the authors, the book “is intended for senior managers who have –or believe they should take – responsibility for developing and overseeing their company’s foundation for execution. Business executives should finish this book with a clear understanding of what they need to do to lead the change and engage their business and IT colleagues in discussions on how to create a foundation for execution…. Building a foundation for execution requires extraordinary IT-business alignment, so both IT and business leaders need to exert influence on the process.” The authors introduce the first discipline for creating the foundation for execution: the operating model and its two key dimensions – business process standardization and integration, and enterprise architecture. Four types of operating models are also described: unification, coordination, replication, and diversification. In discussing enterprise architecture, the authors describe several key elements including: digitized business processes, IT infrastructure, shared data, and customer interfaces. The authors also identify four stages of enterprise architecture maturity: Business Silos, Standardized Technology, Optimized Core, and Business Modularity. They also discuss how companies can derive benefits at each level of maturity by using various management practices and roles. The authors introduce an IT engagement model that has three ‘ingredients:’ IT governance, project management, and linkages that connect the two. They further discuss enterprise architecture as a way to guide outsourcing and in the final chapter provide symptoms of an ineffective foundation for execution. The foundation for execution is “the IT infrastructure and digitized business processes automating a company’s core capabilities. The authors state that a good IT engagement model is built one project at a time and numerous real-world case studies from private sector companies are provided throughout the book. © Journal of Enterprise Architecture – November 2008 30 Book Review Handbook of Enterprise Systems Architecture in Practice Edited by Pallab Saha 2007: IGI Global ISBN 1-599041896 500 Pages This book is a compendium of 26 articles on various enterprise architecture practices from authors around the world that is presented in five sections: Frameworks and Methodologies; Governance and Management; Transformation and Value Realization; Implementation and Deployment; Technology and Service-Oriented Architecture. Pallab Saha is the editor. The book provides a comprehensive and unified overview of practical aspects of enterprise architecture and includes an analysis of EA theory, concepts, strategies, implementation challenges, and case studies. The impact of effective enterprise architecture on IT governance, IT portfolio management, IT risks, and IT outsourcing are described in this authoritative reference tool. Topics covered include: agile and interoperable virtual enterprises; business process modeling; case studies; e-governance; ERP systems; integrated enterprise lifecycle; investment management IT systems implementation; virtual enterprises; and web services. According to the editor, “enterprise architecture (EA) is the organizing logic for a firms core business processes and IT capabilities captured in a set of policies and technical choices. Handbook of Enterprise Systems Architecture in Practice provides a comprehensive and unified reference overview of practical aspects of enterprise architecture. This Premier Reference Source includes a complete analysis of EA theory, concepts, strategies, implementation challenges, and case studies. The impact of effective enterprise architecture on IT governance, IT portfolio management, IT risks, and IT outsourcing are described in this authoritative reference tool. Researchers and IT professionals will gain insights into how firms can maximize the business value of IT and increase competitiveness.” © Journal of Enterprise Architecture – November 2008 31 Book Review Coherency Management: Architecting the Enterprise for Alignment, Assurance, and Agility Edited by Gary Doucet, John Gotze, Pallab Saha, and Scott Bernard 2009: Publisher TBD ISBN: TBD This book is due out in early 2009 and is presented as a collection of ideas (approximately 17 chapters) from experienced enterprise architects around the world. The title of the book; Coherency Management: Architecting the Enterprise for Alignment, Agility, and Assurance conveys the essential elements of the book's message - that the architecture of enterprises should be formalized and promote coherency, and the best way to do this is to adopt Enterprise Architecture (EA) as the ongoing, overarching method for abstracting, analyzing, designing, and re-engineering new and existing enterprises, regardless of the market, industry, or government sector that the enterprise belongs to. EA is about more than technology as it now has strategic and business dimensions, all of which must align to create agility and assurance in promoting transformation and delivering value. Three modes of EA are identified and discussed. The planned Table of Contents includes the following topics: INTRODUCTION: - Introduction to Coherency Management: The Transformation of Enterprise Architecture SECTION 1 - INNOVATIONS IN ENTERPRISE ARCHITECTURE: - The Four Design Models of Enterprise Architecture - Business Engineering Navigator: A Business-to-IT Approach to Enterprise Architecture Management - Framing Enterprise Architecture: A Meta-Framework for Analyzing Architectural Efforts in Organizations - Enterprise Architecture, Strategic Management and Information Management - The Strategic Dimension of Enterprise Architecture - Engineering the Sustainable Business: An Enterprise Architecture Approach - Enterprise Architecture Formalization and Auditing SECTION II - COHERENCY MANAGEMENT IN ACTION: - Issues in Using Enterprise Architecture for Mergers and Acquisitions - Applying Enterprise Architecture for Crisis Management: A Case of Hellenic Ministry of Foreign Affairs - Bridging the Gap between EA Goals and Technology Requirements with Conceptual Programming - The Evolving Role of Enterprise Architecture, Case Study - Syngenta - Realizing the Business Value of Enterprise Architecture SECTION III: ENVISIONING THE FUTURE: LEADERSHIP AND COHERENCY MANAGEMENT - Chief Information Officers, Enterprise Architecture and Coherency Management - Enterprise Architecture for Chief Executive Officers - The Future of Enterprise Engineering; Peter Bernus, Griffith University, Australia - Commencing the Journey: Realizing Coherency Management © Journal of Enterprise Architecture – November 2008 32 © Journal of Enterprise Architecture – November 2008 33 Article The Enterprise Architecture Reference Cube By Gundars Osvalds Abstract This article presents the “Enterprise Architecture Reference Cube” which provides guidance to enterprise architects for concepts used in modeling architecture. The Cube faces represent the dimensions to consider in enterprise architectures – the architectural concepts and their relationships to each other. These relationships are defined between the Cube faces and visually presented in three dimensions. A generic process, using the Cube, is provided for developing Enterprise Architectural artifacts. This process guides the developer of the EA in which products should be used in documenting the EA. The development of the EA Reference Cube is the result of the work of the INCOSE ISO/TC184/SC5 liaison team to update the ISO 15704:2000 standard. Keywords enterprise architecture, modeling, reference cube, process, standards BACKGROUND INTRODUCTION The International Standards Organization (ISO) requested input from the professional community, including INCOSE, in their effort to update the ISO 15704:2000 standard for industrial automation systems - requirements for enterprise reference architectures and methodologies. The ISO specification was reviewed and found to be lacking in presenting relationships between architectural concepts. Therefore, the author developed a complete conceptualization of relationships between enterprise architectural (EA) concepts that could be used in understanding and developing architectures. Issue: How can we display the complex relationships that exist in developing an enterprise architecture? This article describes the “Enterprise Architecture Reference Cube,” which depicts the interrelated concepts used in the development of enterprise architecture models. Multiple concepts and definitions have been created via frameworks and cubes. INCOSE developed an approach that incorporated the guidance from: ISO 19439:2006, Enterprise integration – Framework for enterprise modeling; Institute of Electrical and Electronics Engineers 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems; John A. Zachman, Enterprise Architecture: A Framework; Department of Defense, DoD Architecture Framework; Office of Management and Budget (OMB), Federal Enterprise Architecture (FEA) Consolidated Reference Model; and The Open Group, The Open Group Architecture Framework (TOGAF). © Journal of Enterprise Architecture – November 2008 Need: We must integrate concepts beyond the current ISO influence by adding definitions for other dimensions of enterprise architecture that today's enterprise architects find relevant. Purpose: The EA Reference Cube integrates enterprise architecture concepts to provide one consolidated reference for modeling the elements of a unified framework. Approach: Currently, architectural concepts are depicted as tables, matrices and cubes. Cubes have been used by several practitioners as a convenient way to represent the multiple dimensions of the architectural conceptual space. The author chose a three-dimensional (3D) cube to present the complex relationships within EAs. Each of the six faces of the Cube depicts a key concept used in developing an EA. DEVELOPING THE REFERENCE CUBE The approach that INCOSE used to develop the Enterprise Architecture Reference Cube was to: 34 1. Survey the available literature related to enterprise architecture. 2. Model the concepts, artifacts and their relationships using an Object Management Group's (OMG) Unified Modeling Language (UML) class diagram. 3. Compile definitions of conceptual artifacts. 4. Map the class model to the faces of a threedimensional, cube. Cube References and Resources References included international standards, de facto standards and U.S. government standards form the basis of the Reference Cube’s faces. Resources used included the current versions of ISO 19439 and ISO 15704 are based primarily upon industrial architectural concepts. IEEE 1471 is based on software architecture models. The Zachman Framework is a de-facto representation of enterprise architecture elements. TOGAF uses industry organization experience to document framework governance. The U.S. government has defined the DoDAF and FEA frameworks for use in government programs. Table 1 below details the resources INCOSE used to create the Enterprise Architecture Reference Cube. Table 1. Reference Items Used for the Enterprise Architecture Reference Cube Reference Title Applicable item Use for Cube CONCEPTUAL MODEL From surveying the resources, we identified the following conceptual dimensions related to the development of an enterprise architecture: © Journal of Enterprise Architecture – November 2008 • • Framework: Logical classification and organization of complex information Architecture: Identification of the organizational structure as a system or component and of the 35 • • • • • basis for modeling the enterprise architecture relationships, principles and guidelines governing its design and evolution over time Life cycle: The series of stages in the process of developing an architecture Perspective: The viewpoints of the stakeholders Viewpoint: The collection of perspectives that describe the enterprise architecture Abstraction: The simplified representation or description of the viewpoints used as the Figure 1 below presents a conceptual model showing the basic enterprise architecture ideas and their relationships. Note that the basic, stable relationships are depicted on the Cube with arrows. The dotted lines represent secondary relationships, which the Cube shows on adjacent faces. ArchitectureView Viewpoint Abstraction Figure 1. Basic Concepts and Relationships of the Enterprise Architecture Reference Cube Mapping Thought Process The thought process focused on the question of “How can we present the concepts so that they are readily visualized and understood? “ We created the Cube, using the faces to represent enterprise architecture concepts. We chose a cube as a convenient physical representation of enterprise concepts. In particular, each concept shown in the class diagram maps to a cube face, and the relationships between the concepts in the class diagram are represented by arrows on the faces of the Enterprise Architecture Reference Cube. Framework Concept The framework face depicts a few examples of the frameworks in common use as reference © Journal of Enterprise Architecture – November 2008 architecture Frameworks, as is shown in Figure 2 on the next page. • • • • TOGAF: The Open Group Architecture Framework Zachman: The Zachman Framework for Enterprise Architecture DoDAF: Department of Defense Architecture Framework FEA: Office of Management and Budget Federal Enterprise Architecture The criteria for selecting the examples were based on industry acceptance (TOGAF and Zachman) and government mandates (DoDAF and FEA). 36 Framewor k Figure 2. Frameworks Define the Framework Concept Architecture Concept The architecture face represents the instantiation of architecture using views and models, as shown in Figure 3: • • Enterprise: The objectives that describe the products and/or services delivered to customers. Segment: The bridge between the enterprise vision and the investment in and • • implementation of individual business and information management solutions (OMB 2006). System: The collection of components used to accomplish a specific capability, and a logical representation of the system capabilities. Component: An element of the system. Life History Figure 3. Architecture Levels Describe the Architecture Concept Life History Concept The life history face depicts the architecture’s transition strategy via defined stages, shown in Figure 4 on the next page: • Baseline: The "as-is" architecture, documenting the existing legacy architecture. © Journal of Enterprise Architecture – November 2008 • • Interim Target: One or more interim stages used to complete the transition strategy for the enterprise. Target: The "to-be" architecture. 37 Figure 4. Life History Contains Architecture Plans View Concept The view face depicts the decomposition of architectures from abstract to physical artifacts, as is shown in Figure 5: • • • • Contextual: The forces that influence the values and behavior of the enterprise. Logical: The representation of the conceptual description of the enterprise. Instantiation: The abstraction of the logical description in the form of a physical system that supports hardware and software solutions. Conceptual: The abstract representation of the enterprise. LHistory Figure 5. Views Design the View Concept Viewpoint Concept The architecture perspectives are represented in the viewpoint face, as is shown in Figure 6 on the next page: • Domain: The sphere of concern. • • • Business: The entity that provides products and/or services. System: The logical representation of the business capabilities. Physical: Something real and tangible, such as software and hardware. Life History © Journal of Enterprise Architecture – November 2008 38 Figure 6. The Viewpoints Define the Viewpoint Concept Abstraction Concept The abstraction face shows the abstractions that are used to define the contents of the views defined by the viewpoints, as is shown in Figure 7 on the next page: • • • • • Objective: The detailed representation of what should be achieved Economics: The funding limits and value to be achieved Strategy: The actions to be performed by the enterprise Performance: The quantitative measure characterizing a logical or physical activity • • • • Function: The actions that are being performed to achieve a result Resource: The physical, software and personnel used to deliver the capabilities required Organization: The group of people with shared goals Location: The geographical place The abstractions are a sample of what enterprises may use to describe their viewpoints. These views will be used to define required models and their associated products (e.g., diagram, text, matrix and table). Information: The data and relationships between data elements Abstraction Life History Figure 7. Abstractions Define the Abstraction Concept © Journal of Enterprise Architecture – November 2008 39 Cube Process The Cube concepts can provide guidance in developing architectures. The steps in Figure 8 on the next page show this. Process: • Life History: Pick which Life History is being depicted. • Framework: Pick a Framework. • Architecture: Decide on which type of Architecture is being documented. • View: For the architecture being developed one or more Views should be created. • Viewpoint: Each View may have one or more Viewpoints that represent the use of the • Abstraction: The View and Viewpoint can then is then represented as abstract models using diagram, text, matrix or table. • • • • • Once the Abstraction is modeled one should check if more Viewpoints are needed to represent fully the View selected. Once all Viewpoints are modeled for a selected View one can determine if another View is needed. Then one or more Viewpoints may be modeled and appropriate Abstractions for each Viewpoint should be modeled. Then evaluate if another Architecture is needed to fully represent the selected Life History. If needed develop required Views, Viewpoint, and Abstraction models as guided by the selected Framework. If another Life History perspective is needed then create one or more Architectures and follow the process again. Start ArchitectureiewpointAbstractio Figure 8. Process Steps for Developing Architectures © Journal of Enterprise Architecture – November 2008 40 The Cube Presentation In order to present the concepts of the Cube, we created a three-dimensional model, as is shown in Figures 9 through 15. Figure 11. View Documents the Architecture Figure 9. Framework Guides the Architecture Figure 12. Viewpoint Contains the View Figure 10. Life History Uses the Architecture Figure 13. Abstraction Represents the Viewpoint © Journal of Enterprise Architecture – November 2008 41 Figure 14. Framework Guides Architecture, View, Viewpoint and Abstraction Figure 15. Life History Uses the Architecture, View, Viewpoint and Abstraction © Journal of Enterprise Architecture – November 2008 42 Template Below is a template that you can print out (recommended paper is Card Stock 110lb. or 200g/m2), trim, fold and paste (use a Glue Stick) to create your own three-dimensional Enterprise Architecture Reference Cube. © Journal of Enterprise Architecture – November 2008 43 CONCLUSION REFERENCES The Enterprise Architecture Reference Cube can be useful in presenting architecture concepts to architects. It was developed to help guide architects in providing an understanding of how enterprise architecture concepts are related and how the abstractions are used to develop enterprise architecture products and how they relate to industry and government frameworks. The Cube process guides the Enterprise Architect in the use of the Cube to develop architectures. Department of Defense –DoD (2007). DoD Architecture Framework, Definitions and Guidelines, Version 1.5, April 23, 2007, The Reference Cube concepts have been used as a reference document by the Network Centric Operations Industry Consortium (NCOIC) for its NCOIC Interoperability Framework (NIF) Reference Manual. It was submitted to the ISO 15704 as an example appendix and proposed for conceptual updates to the body. I have also received interest for the Cube use as a teaching aid in enterprise architecture courses by major universities. AUTHOR BIOGRAPHY Gundars Osvalds is a Senior Technology Architect at BearingPoint where he is responsible for directing systems engineering architectural activities in government programs. He consults on using systems engineering processes for architectural design and modeling of enterprises and systems. Mr. Osvalds supports large government transformation programs with systems engineering and architecture tasks, including planning, implementation and reviews of architectural products. Mr. Osvalds has used and supported the DoDAF and OMB FEA architecture frameworks for the federal and DoD communities. Mr. Osvalds is a member of the INCOSE team supporting the ISO/TC184/SC5/WG1 working group, which is consulting with the ISO on enterprise architecture concepts for the next version of ISO 15704 and 42010 (an update of IEEE 1471). He has presented numerous papers at INCOSE and Borland international conferences and at local INCOSE chapters on the advancement of formalized architecture processes and the application of object-oriented methodology in developing architecture designs. © Journal of Enterprise Architecture – November 2008 http://www.defenselink.mil/cionii/docs/DoDAF_Volume_I.pdf. Department of Defense (DoD), DoD Architecture Framework, Volume II, Product Descriptions, Version 1.5, April 23, 2007, http://www.defenselink.mil/cionii/docs/DoDAF_Volume_II.pdf Chief Information Officers (CIO) Council, Federal Enterprise Architecture Framework (FEAF), Version 1.1, September 1999, http://www.cio.gov/Documents/fedarch1.pdf. Institute of Electrical and Electronics Engineers (IEEE), IEEE Standard Glossary of Software Engineering Terminology, IEEE Standard 610.12-1990, December 19, 1990, http://standards.ieee.org/catalog/olis/. Institute of Electrical and Electronics Engineers (IEEE), IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Standard 1471-2000, September 21, 2000. http://standards.ieee.org/catalog/olis/. International Standards Organization (ISO), Industrial automation systems – Requirements for enterprise reference architectures and methodologies, ISO 15704, June 1, 2000, http://standards.ieee.org/catalog/olis/. International Standards Organization (ISO), Enterprise integration – Framework for enterprise modeling, ISO/FDIS 19439, December 2005, http://standards.ieee.org/catalog/olis Office of Management and Budget (OMB), FEA Consolidated Reference Model Document, Version 2.3, October 2007, http://www.whitehouse.gov/omb/egov/documents/FEA_CRM _v23_Final_Oct_2007.pdf. Office of Management and Budget - OMB (2006). FEA Practice Guide, December 2006, http://www.whitehouse.gov/omb/egov/documents/FEA_Pract ice_Guidance.pdf. Open Group, The Open Group Architecture Framework, Version 8.1.1, October 2007, http://www.opengroup.org. Osvalds, G. (2001). Definition of Enterprise Architecture-Centric Models for the Systems Engineer. Proceedings of the INCOSE 2001 International Symposium, Melbourne, Australia, July 2001. 44 https://www.incose.org/ipub/01/CONTENTS/PAPERS/PRES /p414_102.pdf. Osvalds, G. (2004). Use of UML 2.0 Diagrams for Systems Architecture Modeling. The Borland Software Company Conference, BORCON 2004 Proceedings, September 2004, http://conferences.codegear.com/article/32216. Osvalds, G. (2004). Benefits in Using ObjectOriented Methodology for Architecture Modeling. Proceedings of the INCOSE 2004 International Symposium, Toulouse, France, July 2004. https://www.incose.org/ipub/04/PAPERS/411.pdf Osvalds, G. (2006). Use of Architecture for Engineering Systems: The Good, The Bad, and The Ugly. Proceedings of the INCOSE 2006 International Symposium, Orlando, July 2006. https://www.incose.org/ipub/06/054_0833.pdf. © Journal of Enterprise Architecture – November 2008 Zachman, J. (1987). A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276-292, 1987, http://www.research.ibm.com/journal/sj/263/ibms j2603E.pdf. Zachman, J. and Sowa, J. (1992). Extending and Formalizing the Framework for Information Systems Architecture. IBM Systems Journal, 31(3), 590-616, 1992, http://www.research.ibm.com/journal/sj/313/sowa.pdf. Zachman, J. (1998). The Framework for Enterprise Architecture. DM Review, Sept. 1998, http://www.dmreview.com/article_sub.cfm?articleId=422. Zachman, J. (200). Enterprise Architecture: A Framework, Zachman International, January 2000. http://www.zifa.com/framework.html. 45 Article WHICH COMES FIRST, STRATEGY OR ARCHITECTURE? By Tanaia Parker and Tyson Brooks Abstract This article discusses the “chicken or the egg” dilemma between business strategy and enterprise architecture. Presenting the use of strategy as an influencer in determining the enterprise architecture approach, the article progresses by discussing how enterprise architecture may be used to execute strategy and inform the strategic management process. For every enterprise architect working within either the public or private sector, strategic alignment of the enterprise architecture approach should be made as important a priority as the strategic alignment of the enterprise architecture artifacts themselves. In this article, we stand on the premise that an organization’s strategic foundation should serve as the guiding principle for all business management disciplines including the development and maintenance of enterprise architecture. However, we also make painstakingly clear that effective strategy formulation and execution cannot occur without a reliable and actionable enterprise architecture. Keywords strategy, strategic planning, business strategy, business, enterprise architecture, strategic alignment, execution management, business performance model, BPM INTRODUCTION Imagine this...you are the chief architect directed by management to develop your organization’s enterprise architecture. You understand that the executive management team intends to use the enterprise architecture as both a decisionmaking sounding board as well as a guide for executing the strategic directions set. There are a number of frameworks and methodologies in industry that you could use to determine your enterprise architecture development approach. However, you are pondering a very basic question...should you first seek to understand the strategic foundation of the organization (namely, the business drivers and factors determining how the business will operate) before determining the enterprise architecture approach or should you initiate development of the enterprise architecture using a businessbased enterprise architecture methodology with the understanding that the ensuing strategies will be informed by the enterprise architecture that you develop. Basically, your question © Journal of Enterprise Architecture – November 2008 is...which should come first...the strategy or enterprise architecture? business What is Business Strategy? Although in a purely business sense, business strategy refers to the actions taken by an organization to achieve a particular outcome, within the context of this enterprise architecture discussion, business strategy will refer to the factors which drive why and how a business operates. Examples include: (1) the drivers behind the organization’s existence; (2) who the organization serves; (3) the critical success factors, and (4) the “modus operandi” (MO) of the organization. In recent times in the evolving world of enterprise architecture, we have seen more emphasis being placed on the business strategy of an enterprise versus mainly the technology used by the enterprise. With this new, and welcomed, emphasis comes the questions of “where” and “how” the strategic elements of an organization are to be incorporated into enterprise architecture. 46 Historically speaking, strategy has always been the center of the strategic management disciplines of strategic planning and strategic execution. From a strategic planning standpoint, strategy is used to determine an organization’s approach to achieving its vision, strategic goals and objectives. From a strategic execution standpoint, an organization’s strategy should serve as a sounding board for business decisions but also as a guide for how other business transformation initiatives are executed (for example, business process engineering, portfolio management, human capital management and enterprise architecture). It is the latter types of initiatives (which are not typically considered strategic management disciplines) where we have not seen business strategy at the center of the approaches. In fact, business strategy is rarely considered a driver in the development of the approach. Instead, it is usually the organization’s pain point, an industry best practice or some popular management framework that drives these initiatives. For example, within business process reengineering, business process efficiency is usually the guiding principle. Within portfolio management, investment performance is usually the guiding principle. Within human capital management, the needs and capabilities of an organization’s people are usually the guiding principle. Within enterprise architecture, compliance and/or efficient IT management is most often the guiding principle. In this article, we suggest placing business strategy in the center of such business management initiatives – more specifically, in the center of enterprise architecture initiatives as depicted in Figure 1. WHAT IS ENTERPRISE ARCHITECTURE? Understanding that the audience for this article, most likely, has a general idea of what enterprise architecture is, we do not intend to rehash the definition of enterprise architecture. However, a common understanding of what enterprise architecture represents in this article is critical to setting the stage for the remainder of this discussion. To that end, we leverage a simple version of one popular enterprise architecture definition which we believe transcends most others. ..an enterprise architecture serves as a blueprint of an organization that depicts the as-is (current), tobe (future) and transition (intermediate) states. Historically, the determination of an enterprise architecture approach has been based on the guidelines of a pre-determined framework and/or methodology (which is often an industry hybrid) combined with tool and artifact selections customized to align with the organization’s intended use of the enterprise architecture. In general, we do not disagree with this formula. However, we do question how a “strategicallyaligned” enterprise architecture (which is, generally, the goal of most enterprise architecture efforts) can result from such a formula. Determining the enterprise architecture approach without first understanding the strategic underpinnings of the organization makes the mere development of the enterprise architecture a higher priority than the development of a truly, strategically-aligned enterprise architecture. The strategicallyaligned enterprise architecture is not just the enterprise architecture that includes strategic elements within the set of artifacts stored within the repository, nor is a strategically-aligned enterprise architecture one that simply shows “line of sight” between the strategic goals and objectives of an organization and its investments. A strategically-aligned enterprise architecture is one in which the strategic foundation of an organization stands at the center of enterprise architecture development, maintenance and use. HOW STRATEGY INFLUENCES ENTERPRISE ARCHITECTURE Figure 1: Business Strategy at the Center of Enterprise Architecture © Journal of Enterprise Architecture – November 2008 As previously mentioned, strategy represents the underlying, driving forces and MO of an organization. Given this, all business decisions 47 should reflect the strategy’s influence. Within the realm of enterprise architecture, the business strategy should not only serve as supporting artifacts but also influence the need for enterprise architecture (i.e., the “why”) which then drives out the “who” (audience), “what” (content) and “how” (methodology) questions relevant to an enterprise architecture approach (see Table 1 below). Together, these elements provide the requirements for how the enterprise architecture will be developed, used and maintained. How Does Strategy Influence EA? Why: Defines Why EA Exists Who: Defines Who the EA Is Being Built For What: Defines the EA Content How: Defines the EA Governance Structure Table 1. How Strategy Influences EA WHAT DOES STRATEGY HAVE TO DO WITH ENTERPRISE ARCHITECTURE? “Strategy” relates to a plan, method or series of maneuvers (or stratagems) for obtaining a specific goal or result (Random House Unabridged Dictionary, 2006). Consequently, all initiatives (not just the strategic initiatives) taken on by an organization must align with the strategy set forth at the outset. This means ensuring that operational plans/tactics clearly support the strategic direction of the organization while ensuring that the plans for execution are laid out so that the strategic implementers (e.g., business managers, administrative assistants, machine operators, business developers, human resources, IT managers, etc.) know exactly what their part is in executing the plan. Now, how does all of this © Journal of Enterprise Architecture – November 2008 relate to enterprise architecture? Well, separate from ensuring that the strategic elements of an organization are represented in enterprise artifacts (the details of which are outside the scope of this article), the strategic foundation of an enterprise should also drive what we call the “Why, Who, What, and How” of the enterprise architecture approach (see Figure 2 on the next page). Below, each of these perspectives is discussed in more detail. The Strategic “Why” of Enterprise Architecture The strategic “why” of enterprise architecture takes into consideration the reasons an organization exists and translates these reasons into drivers for pursuing an enterprise architecture. As we touched upon previously, the discipline of enterprise architecture is maturing to a point beyond IT investment management to include supporting the business of an organization as a whole. To this end, it is critical for organizations to understand exactly why an enterprise architecture initiative is needed by the organization to support its mission. The key point here in answering the strategic “why” question is that the business driver for developing and enterprise architecture is put directly into the context of the business purpose versus being confined to an IT management, process improvement or data management box. This level of reasoning is considered within the strategic realm because the answer to the “why” question will help to determine the enterprise architecture methodology, framework, artifacts, maintenance and execution approach. In other words, the answer to the “why” question will help to determine the plan, method and/or series of maneuvers (i.e., strategy) for obtaining an enterprise architecture that not only meets the needs of the organization but also be developed in such a fashion that the maintenance of the enterprise architecture will be integrated into business operations. 48 Figure 2. The Why, Who, What, and How of Business and Enterprise Architecture Strategy The Strategic “Who” of Enterprise Architecture The strategic “who” of enterprise architecture has to do with the stakeholders of the organization as well as the intended audience of the resulting enterprise architecture. Too often we forget that there are individuals and external groups beyond our direct customer’s base that must be considered when business decisions are made. Giving adequate attention to the “who” question will not only ensure that the business covers all bases as it pursues accomplishing its mission but from an enterprise architecture perspective, it will also define the criteria and sets the boundaries for the types of artifacts to be developed, the transition strategy detail and framework leveraged. In other words, the answer to the strategy “who” question will enable you to develop an enterprise architecture that speaks the language of your targeted audience versus the creator of a framework. The question of “who” is considered within the strategic realm because the response to this question determines the requirements for how the enterprise architecture has to be presented (i.e., informs the strategy for enterprise architecture development). Will the enterprise architecture be made up of © Journal of Enterprise Architecture – November 2008 Business Process Model Notation (BPMN) models that are contained in a repository with a high-tech portal front end that will be appreciated by semi-technical individuals? Or, will the enterprise architecture be designed to be accessible by the aging workforce who rejects PDA technology and wants the typewriter back yet still needs to understand their place in executing the business plan (yes, this represents one of my clients!). The Strategic “What” of Enterprise Architecture The strategic “what” of enterprise architecture speaks to the specific offerings and value proposition of the organization as well as the offerings and value proposition of the enterprise architecture. The offerings and value proposition of the organization is usually an easier question to answer than that of enterprise architecture. The organizational value proposition usually represents the products and services provided to the organization with some undercurrent of its area of differentiation. The enterprise architecture value proposition question, on the other hand, has to do with the specific “helps” and/or resources the enterprise architecture provides. Discussions about the enterprise architecture value proposition have flooded industry recently with questions ranging from whether the value of enterprise architecture 49 can truly be determined to complicated calculations of return on investment. The truth is that the enterprise architecture value proposition can only be defined within the context of the organization’s answer to the strategic “why” question”. The question of “what” is considered within the strategic realm because the response to this question is truly the strategic plan for the enterprise architecture. The Strategic “How” of Enterprise Architecture The strategic “how” speaks to the “operating model” of both the business itself as well as enterprise architecture development and maintenance efforts. As we learned from the work of Jeanne Ross et al. (2006) in “Enterprise Architecture as Strategy”, enterprise architecture reflects the requirements of an organization’s operating model. With an operating model serving as a depiction of how a business is organized and run, the answer to the “how” question with respect to enterprise architecture drives what policies, procedures, guiding principles, practices and governance structure will be needed for the organization’s enterprise architecture initiative. Furthermore, the maintenance of the enterprise architecture needs to be an integrated facet of the business thereby designed to align with the operating model of the business. If the organization operates within a fast-paced environment characterized by iterative improvements and collaborative consensus, then your enterprise architecture should be developed to support this type of operating model. Otherwise, it will not deliver maximum value. The question of “how” is considered within the strategic realm because the operating model itself (i.e., how the business and/or the enterprise architecture will be managed) is a strategic decision all in itself. HOW ARCHITECTURE EXECUTES STRATEGY Enterprise architecture provides organizations the means for delivering continuous improvement for decision-making, transition strategies and measurements of business systems performance to meet the mission of the organization. Where enterprise architecture typically exists as a dynamic process of current, © Journal of Enterprise Architecture – November 2008 future and transition state representations (which provides actionable insight to organizations about where it currently stands and how it will transition from its current state to a desired future state), business strategy serves as the guiding principles for enterprise architecture development and use as well as stakeholder interactions with the enterprise architecture and determination of the artifacts maintained within the enterprise architecture. Both strategy and enterprise architecture must be approached together to effectively guide and manage the enterprise. Considering the statements above, it should be obvious, then, that enterprise architectures play a central role in executing strategy. The enterprise architecture provides the link between the strategic goals of the organization and the enabling capabilities needed to provide services to its customers. The enterprise architecture process captures the business requirements and transforms them into solutions that can be understood by executives, senior managers and other staff required to execute the solutions. Additionally, the enterprise architecture should provide a firm understanding of what the organization requires today and provide the guidance (or roadmap) for how the future architecture may alter those needs. The existing enterprise architecture interprets current needs, which usually leads to strategy development, and lays out a preliminary sketch of future requirement needs while remaining responsive to change. The existing enterprise architecture also determines the most operationally sound, technically feasible, and cost effective program investments which support the strategic initiatives within the organization. The balance among the present architecture, customer needs, future flexibility, and cost are the domain for strategy development in most organizations. The Role of Enterprise Architecture in Strategy Execution Enterprise architecture plays a key role in executing strategy in that it provides actionable insight into an organization’s business model. An enterprise architecture should highlight capabilities from both an individual operations perspective as well as from a collective, interoperation perspective. Therefore, an organization’s existing enterprise architecture should make clear the boundaries for how the organization’s infrastructure can be manipulated to execute strategy, as is shown in Figure 3. 50 Weill et al. (2002) suggest that infrastructure capability is an important metric in understanding how IT can enable or constrain business initiatives. The significant distinction of enterprise architecture is in its focus on the capabilities to support the organization from the assemblage of strategy and its function as an informer to the formulation of strategic and business initiatives for the organization. Figure 3. Architecture to Strategy Execution The existing enterprise architecture of the organization provides the foundation for building the capabilities needed to execute strategy and supports the development and implementation of the business (or operating) model. The enterprise architecture, when viewed in parallel to the organizational infrastructure, can be defined in terms of (1) the business processes, people capabilities, applications, data, and technology which are central to the operations of the organization and involve the comprehension and aptitude required to effectively support the existence of the organization. The enterprise architecture embodies the configuration of © Journal of Enterprise Architecture – November 2008 technologies, business processes, and operations that not only build and sustain present and future business needs but is also the foundation of executing the organization strategy. Often doubted by stakeholders, another role of enterprise architecture is demonstrated in its inherent ability to depict organizational transformation and agility through transition artifacts and showing how an organization will adapt to environmental changes. In today’s world, organizations’ business models must change more frequently than they did in the past 51 to adapt to new market opportunities. Architectures are also expected to adapt and exhibit more versatility in technological changes. Organizations must have some level of technology attentiveness to support strategy which involves a genuine commitment to enterprise architecture within the organization. Executives and senior managers must maintain an awareness of the market and be able to identify technology innovations. These individuals need to keep abreast of both technological advances and better ways to operate in order to adequately inform strategy formulation within their respective organizations. Successful strategy execution is a direct outcome of a clear alignment between business strategy and the enterprise architecture approach. To that end, enterprise architecture must serve the role of linking business strategy with the operational elements of an organization (namely, business processes and the technical architecture) as displayed in Figure 4. Specifically, this means that enterprise architecture must assist organizations in making clear choices about what internal capabilities are necessary and how best to position an organization given the existing infrastructure. Figure 4. From Business Strategy to Architecture Enterprise Architecture as a Strategic Advantage The organizational capabilities identified through a strategically-aligned enterprise architecture provides the infrastructure necessary to effectively execute strategy. Leveraging technology to further enhance the alignment between strategy and architecture provides an operational advantage for most organizations. For example, Davis and Davidson (1991) state that by the year 2020, 80% percent of business profits and market values will come from the part of the enterprise that is built around the business of information. As market demand and customer needs change, architecture alignment to business strategies must keep pace. It is in such situations that efficient relationships are defined. © Journal of Enterprise Architecture – November 2008 Effective positioning of the organization in the market is crucial to its ability to adapt and effectively leverage technology. Interoperability gives technology the opportunity to provide competitive advantage. Ross et al. (2006) suggests an effective foundation for execution depends on tight alignment between business objectives and IT capabilities thus signifying that these factors contribute to successful execution of strategy. By organizing the objectives of executives, senior managers and business managers, it is assumed that organizations can outperform those without such alignment. Using these objectives, one can identify the factors that should be considered by management in accomplishing effective architecture alignment and business strategies. 52 STRATEGIC ALIGNMENT, WHO CARES ANYWAY? Strategic alignment addresses the problem of coordinating the relationship between the business domain and the information technology (IT) domain (Simonsen, 1999). Strategic alignment results in a clear identification of the advantages and patterns of events that create strategic value and produces monetary gains for the organization. Consequently, business operations and IT must reflect the strategyarchitecture alignment. One of the biggest challenges for executives and senior managers is the misalignment of enterprise architecture with the organization’s business strategy. J. Varghese and P. Kurien (2004) state that “organizations often suffer from an artificial wall between the people with the problem (usually business management and users) and the people with the solution (individual front line staff and IT project teams)”. Therefore, as represented in Figure 5 below, the elements of strategy alignment and change involve a combination of business and technical architecture, human resources and overall direction. These elements together form a concrete platform for successful strategic execution. Figure 1: Foundation for Strategic Alignment and Change As strategic change is about well-informed transition from one state to another, executives must first ensure that each of these foundational elements of strategic alignment and change are addressed. As these components are analyzed and structured, the needs of the organization are evaluated for comprehension. When the components reach an expected state of completeness, the alignment to strategic © Journal of Enterprise Architecture – November 2008 initiatives for the organization is presented for acceptance. Once accepted, the outcomes become the influence for the development of the organization’s business strategy. Business and Technical Architecture Typically, both the business architecture and the technical architecture are managed separately and thus become very difficult to combine into a common understanding (or view) of strategy. In order to get a consistent view, executives need to first understand and document the organization’s current architecture to cover the appropriate areas. The current architecture is important to the enterprise because it establishes (and verifies) what resources (including IT), direction and tasks are being used in line of businesses to support the achievement of existing strategic goals (Bernard, 2005). Once the architecture has been harmonized, then the aggregate of technology and data can help with the identification of patterns of customer needs, trends and future opportunities. Analytics, such as customers and sales and marketing data, should already be identified if the organization has performed this step and is delivering business intelligence (BI). Since these analytics roll into the overall architecture model, operational metrics should feed customer scorecards for determining customer satisfaction. Executives would certainly value an architecture that assists executives in understanding how the organization supports its customers and position in the marketplace. Human Resources Every resource (i.e. manager, employee, line worker, etc.) within an organization must be involved with strategic alignment. Executives have a fundamental responsibility to communicate strategic initiatives to those who must then convert the initiatives into actionable plans. Executives and management must also ensure that the organization has the right resources with the right skills, the right attitude and have the right support to adequately perform their job of achieving to perform the organization’s strategic objectives. Management must motivate these resources through rewards and/or incentives. Unless resources have real enticement to implement the strategy, they will not commit to it and the alignment to strategy more than likely will fail. 53 Direction Management’s ability to direct the organization through various projects and tasks should not be understated. Lack of clarity in the direction of the organization is a common obstacle to effective strategic alignment. Therefore, the direction must describe the measures that translate strategy into actions and be submitted to continuous managerial attention. Establishing clearly defined and reproducible organizational processes (i.e. strategy maps, SDLC, EA, etc.) are key for strategic alignment. These processes provide the organization with important collaboration points and allow management and employees to share the overall corporate view, interact with other team members and prove their worth to the organization on tactical efforts. Great care and effort must be put forth to reach all individuals and to increase the strategic awareness throughout the organization. Successful strategy execution is supported by a coherent and reinforcing set of processes and organizational structures. Alignment amongst architecture, resources and direction adds value to the organization because individually and collectively they support the overall strategic direction instead of just tactical goals for the organization. These represent the cornerstone components for the success of strategic alignment and the foundation for developing strategic capabilities within the organization. DEVELOPMENT OF STRATEGIC CAPABILITIES – AN ARCHITECTURE FORMULATION VIEW The role of strategy in enterprise architecture has evolved from a focal point on the consolidation of various technologies to a focus on ensuring that all aspects of the business (technology and otherwise) directly supports the mission of the business. The execution of business strategy calls not only for an increased focus on architecture development to make the direction of an organization clear but it also requires that enterprise architecture makes certain that IT is in a position to effectively respond to ever increasing business needs. Organizations are beginning to understand that the best strategic planning efforts are not confined to what exists in their IT environments today but where the market and customer needs are driving them. © Journal of Enterprise Architecture – November 2008 The foundation of any successful enterprise architecture initiative is not only to model the business, systems, and other infrastructure components within the environment but to also understand how they cooperatively function to deliver services for the organization to meet its strategic objectives. Enterprise architecture performs a powerful role in this endeavor in that it contains data and information that inform business strategy development. Through the insight provided by enterprise architecture, the strategy development process is able to better identify the strategic capabilities required to achieve the results sought. The Adaptation of Strategy to Architecture – Execution Management Informed strategic planning requires that organizations have a solid understanding of the external factors affecting the organization as well as its own, internal architecture capabilities. As organizations continue to move from mainframe applications toward distributed business systems to solve business problems, strategy provides a robust sounding board for developing an infrastructure that looks to drive, influence and control all aspects within the organizations enterprise architecture (see Figure 6 on the next page). In order to ensure that business requirements remain the focal point for IT initiatives, a welldefined approach to enterprise architecture that centers around the business is needed. Taking a stance that enterprise architecture is not about technology, enterprise architecture should focus on the relationship between an organization’s make-up and how these components of an enterprise can be managed to deliver on the organization’s mission and strategic goals. Furthermore, enterprise architecture is about (1) aligning capabilities with mission and strategic direction, (2) developing and maintaining an actionable plan, and (3) presenting a decisionmaking sounding board that is relevant to all enterprise players (Parker, 2007). Since strategy must be executed in order to reap benefits, the enterprise architecture must capture, produce and expose components and artifacts that support strategy implementation. Additionally, the enterprise architecture must depict change across the organization and improve the ability to associate costs with business value and benefits. 54 Figure 6. Strategy Provides a Robust Sounding Board Execution must be performed by an organization to leverage many of the existing processes used to manage increasing customer and business changes. By linking strategy with sound execution management, an enterprise architecture helps organizations to achieve the desired goals and organizational progress while also delivering consistent metrics-driven results for success. By providing the organization with a consistent approach for managing business change as corporate strategy is driven forward, execution also delivers value by tracking incremental progress associated with A strategic vision is a desired endpoint. The hard work comes when an organization must identify the pathway and the milestones (i.e. through projects) needed to achieve the vision. Just because the organization established the vision this year, does not mean that business strategies must remain unchanged. In fact, good strategy execution requires that business strategies be dissected into actionable milestones with these milestones comprising the strategic roadmap for the organization to follow. Just as the market and business environment change, so must an organization’s strategic management infrastructure need to be flexible, agile and adaptable to accommodate the changes in the environment. Applying Enterprise Architecture to Identify Strategic Capabilities Identifying strategic capabilities through enterprise architecture requires a collaborative © Journal of Enterprise Architecture – November 2008 development process. By applying an understanding of market changes and customer needs to the business strategy development process, the creation of what is called a Business Performance Management (BPM) model is possible. A BPM provides an organization with a performance model driven by metrics that aligns the organization with the business, customer and market requirements it must meet. From this exercise, organizations are able to identify the business processes and services (strategic capabilities) that are used to deliver the metrics which address the requirements. In turn, organizations can then determine which business processes/services need to be modified, added or removed. To begin the process, organizational business processes should be modeled into a business process model (BpM). Once the BpM has been created, simulations can be run against the BPM to determine how well the metrics have been adjusted to address the roadmap targets identified from the business strategy. Once the list of changes to business processes is identified, specific operations and systems are identified, prioritized and adjusted accordingly to the strategic direction of the organization. Change management and the associated timelines for implementing these “deltas” effectively represent the tactical roadmap, which is used to drive changes to develop the organizations enterprise architecture. Figure 7 on the next page provides a view of how these models align. 55 Figure 7. Enterprise Architecture Development Strategy and Future Organizational Direction Strategic execution is compounded by changing market conditions, trends, customer needs, mergers and acquisitions, and unnecessary IT purchases. The intricacy of developing strategy has a major impact on an organizations future manageability, and operations costs. IT environments are more expensive to manage, more difficult to operate, and can yield unpredictable results when strategy is introduced and not properly managed. The future of an organization must still be planned for despite a dynamic and innovative environment. Similarly, organizations must continue to make the appropriate investments in strategy, architecture, internal culture, organization, and technology despite the changes that abound around them. The good news is that an intentional focus on effectively managing the strategy development and execution processes will allow enterprise architecture to emerge as both a strategic and change management agent for organizations seeking to rein in difficult-to-manage business and IT environments. CLOSING THOUGHTS Strategic changes lead to operational changes which ultimately lead to infrastructure changes (i.e., systems upgrades, network changes, security profiles) which all can occur continuously. Strategic change is a well-known challenge for organizations and will continue to confront executives as business becomes even © Journal of Enterprise Architecture – November 2008 more complex and dynamic. Without insight into an organization’s environment or how elements within an organization relate to one another or how well the elements of an organization can adapt to foreseen adjustments, any move made by an organization is laden with risk. If organizations are still pondering the basic question…which should come first- the business strategy or enterprise architecture then we believe the answer is simple — “business strategy”. By understanding these challenges, how can organizations get a fully accurate picture of the systems, applications, and other infrastructure components in the environment? First, organizations must embrace sound business strategy development using enterprise architecture to continuously inform the process. Ultimately, through strategy, organizations want to select and implement the right projects and investments to support the organization’s mission and goals. This requires collaboration within the organization to ensure a clear understanding of business needs and objectives, and to ensure that proper enterprise architecture guidance is provided to support the business. Equipped with these key prerequisites, the enterprise architecture can provide the proper insight and infrastructure to support business needs, support the appropriate groups to lessen exceptions to standards and maintain insight of the architecture environment. Second, it is important for organizations to understand that business strategy must influence the need for enterprise architecture 56 (i.e., “Why, Who, What, and How”) in executing strategy. The complexity of strategy execution can be reduced with a defined enterprise architecture structure. The execution of strategy is supported by standards and processes. While there is no magical solution for developing strategy, a strategy development process which leverages enterprise architecture can provide the insight and execution framework necessary to yield successful strategic planning results. Finally, by intentionally pursuing strategy alignment in enterprise architecture, organizations will realize improvement in the development of systems, applications, and other infrastructure components which, in turn, will result in these components functioning collectively to achieve organizational goals. These elements will ensure that an organization embodies the foundation that is essential to the enterprise architecture's ability to realize business benefits for the organization. In closing, there is still a silence concerning the degree to which an organization’s strategic make-up should determine how enterprise architecture is approached. As practitioners within the enterprise architecture discipline, we should be more diligent in demonstrating the value of enterprise architecture without pushing a particular methodology, framework or tool. If we continue to look at enterprise architecture as an asset and resource whose very make-up must be defined by the strategic needs of the organization it is created for, then we will have significantly contributed to the maturation of the discipline. AUTHOR BIOGRAPHIES Tanaia Parker Tanaia Parker is founder and president of T. White Parker, a strategy and management consulting firm specializing in enterprise problem solving and strategic management. For more than 15 years, she has worked as a strategy consultant, enterprise architect, and business advisor to various levels of management within multi-billion dollar companies, public-sector organizations, and emerging startups. Her breadth of experience has helped to create a unique perspective and approach to strategic management and enterprise architecture. Ms. Parker has a bachelor’s degree in business administration from The American University © Journal of Enterprise Architecture – November 2008 and an MBA from The George Washington University. Ms. Parker can be reached at [email protected]. Tyson Brooks Tyson Brooks is a Senior Enterprise Architect with BAE Systems Information Technology and has spent the last 11 years working on a wide range of consulting assignments covering Strategic Planning, Business Process, Reengineering, Enterprise Architecture and IT Investment and Capital Planning. Mr. Brooks has extensive experience in conceptualizing, creating and maintaining key parts of the Federal Enterprise Architecture (FEA) framework. Mr. Brooks has a Master of Science (MS) degree in Information and Telecommunications Systems from Johns Hopkins University, a Master of Business Administration (MBA) degree from Thomas More College and a Bachelor of Science (BS) in Business Administration/Management from Kentucky State University. Mr. Brooks can be reached at [email protected]. REFERENCES Bernard, S. (2005). An Introduction to Enterprise Architecture. Bloomington, IN. AuthorHouse. Davis, S. and Davidson, B. (1991). 2020 vision: Transform your business today to succeed in tomorrow’s economy. Fireside Books, NY. Parker, T. (2007). Enterprise Architecture as a Discipline for Strategy Execution. Executive Report, Vol. 10, No. 12, Cutter Consortium. Ross, J., Weill, P., and Robertson, D. (2006), Enterprise Architecture as Strategy. Boston, Harvard Business School Press. Simonsen, J. (1999) “How do we take Care of Strategic Alignment? Constructing a design approach”. Scandinavian Journal of Information Systems (11), pp. 51-72. Varghese, J., and Kurien, P. (2004). IT Imperatives beyond strategic alignment: enterprise architecture flexibility and IT delivery efficiency. Handbook of Business Strategy, pp.275-279. Webster’s Unabridged Dictionary (2006). Random House, Inc. New York. Weill, P., M. Subramani, Broadbent, M. (2002). Building IT Infrastructure for Strategic Agility. MIT Sloan Management Review. No. 44, p. 57. 57 Case Study Improving Government Performance Through Enterprise-Focused Development By Alex Glaros Abstract This case study article introduces the concept of Enterprise-Focused Development (EFD) as a part of a repeatable method for improving productivity in government agencies at federal, state, and local levels. EFD does this by promoting a project management approach that links business analysis and data modeling methods. EFD also takes an enterprise-level architected view to reducing software expenses and creating higher quality computer systems. In keeping with newer methods, EFD promotes the use of highly productive project teams and frequent iterations with clients to develop IT systems to avoid long delivery timeframes and performance failures that often came with early project management approaches and lifecycle development approaches, such as the ‘Waterfall’ method. In this way EFD has the potential to save government agencies significant time and resources in developing IT systems. Keywords enterprise-focused development, government, productivity, service-oriented architecture, data modeling, business analysis, agile, waterfall, methodology INTRODUCTION My ideas for improving government interoperability and development methods formally began when listening to FBI Director Robert Mueller’s testimony before Congress that the lack of connectivity between government data systems was partly responsible for the failure to identify 9/11-related security threats. I recognized a similar lack of interoperability within all government, and define the root problem as an absence of data modelingguided, enterprise-wide, business process design. This case study article introduces the concept of Enterprise-Focused Development (EFD) as a part of a repeatable method for improving productivity and interoperability in government agencies at federal, state, and local levels. EFD does this by linking business analysis and data modeling methods as well as taking an enterprise-level architected view to reducing software expenses and creating higher quality computer systems. Applied to all federal and state government, EFD has the potential to save hundreds of millions of dollars in direct IT systems development costs, and additional savings are gained if the higher quality systems © Journal of Enterprise Architecture – November 2008 have lower maintenance costs and require less frequent updates. The Standish Group, a world leader in constructive analysis of project failures, published a study showing that large IT projects fail or are challenged more often than succeed. The traditional ‘Waterfall’ IT system development methodology has been mentioned by the chairman of the Standish Group as a major reason for project failure (Johnson, 2006). EFD methodology addresses many of the reasons for systems development failure and therein has the potential to save government substantial sums of money. IMPROVING PRODUCTIVITY WITH ENTERPRISE-FOCUSED DEVELOPMENT The basis and context of using EFD to improve productivity in government agencies is a threeelement repeatable process that links business analysis, data modeling, and enterprise-focused development, as is shown in Figure 1 on the next page. 58 Figure 1. Enterprise Focused Development and the Highest Productivity Methodology This productivity improvement process in a government agency begins with effective use of business analysis, which drives data modeling, which in turn is implemented with EFD. The cycle is repeated across the enterprise such that the agency's data is continuously and nimbly refocused. I refer to this frequent refocusing of IT to business requirements as “super alignment to government's mission”. The relationship of these three elements is further articulated as: • • • Business process improvement requirements gathered from many sources, such as business process management activities, by a data architect drives: Prioritized enterprise-mindful table modeling to align IT quickly to requirements. Programming code and finished product are implemented by: Enterprise Focused Development, which uses data modeler led development teams and creates high quality systems guided towards enterprise integration. Every government information executive should ensure that the above process is operational in their organization. Once this productivity improvement process becomes repeatable and institutionalized, agencies should notice an organization-wide change where new services are rapidly delivered. THE ENTERPRISE-FOCUSED DEVELOPMENT METHOD Enterprise Focused Development uses relational data modeling to focus software development teams in the most effective way possible while building the organization's enterprise © Journal of Enterprise Architecture – November 2008 architecture. EFD is a method for creating computer software systems by modeling the whole system, then building the code in very small increments and having the client test the small increments before making additions to the system. This makes the client an involved partner throughout system design and implementation. EFD’s flexible method contrasts sharply with conventional methods, such as Waterfall methodology, where clients' specs are obtained in the early phase of system design, then designers and programmers follow rigidly planned building steps until the system is completed and presented to the client for testing as a finished product. The power of EFD's method stems from its ability to handle change as it happens. Change is inevitable and comes in many forms: • • • Clients often envision better design ideas after they see actual working components in action. If they are unable to see parts of the system in action early on, and influence design on an ongoing basis, then many improvements are permanently lost Legislation mandates change The data environment changes such as when related systems are introduced or undergo changes EFD resolves change related problems by addressing them as they occur. Here's a typical example. Suppose the creation of an appointment scheduling system for a governor's office is requested. During initial interviews it is determined that the system should work with time units that are a minimum of 15 minutes. 59 With EFD, a simple menu would be available to the governor's staff within a few weeks just for adding test records. Nothing else has been coded or committed to, just rough data entry programming code for adding meetings. During input of actual data the governor's staff realizes that 15 minutes is too large of a time frame and requests that the minimum unit be reduced to 1 minute. Analyze the difference in the way the methodologies handle change. With EFD, the correction is made early. With conventional methods, the problem is not caught until the whole project is completed and handed to the client for testing months or years later, but now the error is embedded in thousands of places throughout system code and data files. Multiply this example with many other problems and oversights in a very large project and you can see the advantages of EFD. If we were looking at a large IT project, there could be several scenarios in going with a conventional development methodology. • • • Best case scenario: The change regarding 15 to 1 minute units goes to a change control board and is approved and problem is repaired, raising the cost of the system. Bad case scenario: The change control board views this as scope creep and denies the change. Worst case scenario: Contract lawyers become involved as the client and project manager argue in court over whether the system requirements were met under the contract's definition. EFD on the other hand has the potential to significantly improve client satisfaction because the client is an ongoing partner in the development of the system. Even if you start off in the wrong direction, Enterprise Focused Development corrects the project early on. • • • • Misunderstandings project team between client and Missed requirements Incorrect requirements © Journal of Enterprise Architecture – November 2008 Incorrectly configured hardware and system environment. Conventional methodologies accrue problems until the first finished version of the project is handed to the client for testing. The complexity of the problems can overwhelm project managers who then fulfill project management's first rule: most projects fail. EFD works best for business systems where prototyping software is easy, and is least effective where blueprints must be rigidly followed such as when building a submarine. I named the methodology “Enterprise Focused Development” because a data modeler uses Enterprise Architecture-mindful table design to focus the whole project's development effort. EFD has some similarities to the Agile™ software development methodology (http://agilemanifesto.org/). With EFD, I replace the traditional Agile concept of self-organizing teams with data modeler-organized teams. This puts the development team in sync with: • • • • Its members when the project is very large Project-wide integration Enterprise-wide data integration/Enterprise Architecture The organization's mission. ENTERPRISE-FOCUSED DEVELOPMENT AND THE DATA MODELER Critical to the success of the project are (a) strict normalization of data as it changes, and (b) having the data modeler be the project designer, requirements gatherer, and project leader. The data modeler must be the requirements gatherer for the following reasons. • The EFD methodology flushes out problems in the system during each step of the process. Some common problems that get flushed out include: • Design weaknesses • The data modeler can visualize data connections with obscure regions of the organization, or other organizations, down to the field level, possibly eliminating whole processes that the conventional project manager or requirements gatherer cannot imagine or mistakenly believes are requirements. Questions to clients can then include connectivity and enterprise architecture related areas early on instead of as an afterthought. This saves the organization 60 • • • from veering off into silo territory and strengthens the enterprise architecture. A data modeler can ask questions that reveal subtle requirements that are difficult for nonmodelers to imagine. The data modeler sees Service Oriented Architecture (SOA) opportunities for internal use or for external organizations in the current project that other disciplines cannot imagine, and begin researching this area so that potential stakeholders receive an early heads-up regarding collaboration potential. The data modeler is less likely to confuse a process with a true requirement. The data modeler is more capable of envisioning ways to re-engineer a process through their understanding of the data and ask opportunity-creating questions during requirements gathering. To receive requirements secondhand would be a loss of this opportunity, increase time and cost of the project and make project impact analysis superficial, missing deeper effects on the organization's operation. A data modeler should be considered to be the EFD project leader because controlling the project via tables is the key to keeping thousands of components in sync with each other and the project's mission. This is especially valuable in controlling code building by large programmer teams in big projects. The same is true for the system designer. If instead of a data modeler, a process oriented project designer was used, serious weakness would be introduced into project design because complex or changing requirements cannot be addressed rigorously with a process viewpoint. Roadmap to a Successful Project The following are the steps to use when implementing the EFD methodology. 1. Gather all requirements. Be prepared to flexibly modify requirements throughout the process, even towards the end of the project. 2. Model the data. Be prepared to flexibly remodel data on a daily basis. The whole system from beginning to end should be modeled. This is only the first iteration of modeling. No program code has been written yet but the complete system workings are revealed by the data design. Data tables document requirements better © Journal of Enterprise Architecture – November 2008 than paper format, however business rules notes should accompany each table's design where clarity is needed. Enterprise Architecture and SOA should be designed in during this phase and into each iteration as is described here. As each table is created it should be: a. registered in a database defining its sharable potential such as Web Services or simple file exchange potential b. evaluated regarding considerations c. security evaluated for use in BI, including executive and legislative summaries d. evaluated for possible metrics use and have its metrics capability loaded to a metrics registry 3. Create user interface (menu screen) based upon client's requirements and ghost out everything except for data entry, find, view, edit and delete options for the very first table only. It is not necessary to make the menu extremely detailed on the first day. Start with a simple rough overview. 4. Build programming code for the first find, view, add, delete and edit screens for the first table 5. Ask the client to add the first few records and start providing feedback 6. Add another feature based upon client feedback. Each time a feature is added, repeat the above process. The more frequent the iterations, daily is the best, the more efficiently will the project proceed. This involves far more frequent prototyping iterations than the Spiral Model of software development (Boehm, 1998). Make sure to personally visit or get the client feedback process fine-tuned daily so that a comfortable working relationship exists between the modeler and the client. Keep the daily meetings short. Now client trust has been built by (1) visible quick progress (2) the establishment of a repetitive communication pattern with the modeler. The goal is to bring client interaction with the modeler to where it is a daily habit and to encourage frank communications on complex issues. At mid-point, clients see so many new features and unexpected capabilities created by relational table 61 flexibility that their enthusiasm builds into strong project acceptance. 7. The menu layout and data schema need to change quickly, daily, to perfectly capture the client's goals, which will evolve during the process in a manner most likely to make the project succeed. Never vary from strict third normal form (Codd, 1971). This will allow the whole system, no matter how large, to turn on a dime and align itself to the client's ongoing requirements changes throughout the whole project. This is the heart of EFD. Continuous data re-modeling is the agile component of this methodology. Should anyone besides a data modeler be in charge of the project, agile table modeling that aligns the project to improving requirements would be lost during bureaucratic delays, draining the lifeblood from the project and adding expenses tied to delays in correcting requirements errors. A data modeler agilely tuning the project to requirements is the core process responsible for EFD's tremendous potential for cost savings. This process creates a steady rhythm of feature completions that builds client trust and support for the project. 8. Programmers, especially contractors, should not be allowed to create tables (or arrays, which should be banned from all projects) but they should be encouraged to discuss and recommend table design to the data modeler who will correctly design them to fit into the enterprise-wide picture. In essence, the data modeler is directing the project through table design, and programmers, database administrators, server teams, webmasters, etc. are filling in the details. This personnel organization is less dependent upon highly skilled programmers since the database design drives the project towards robust stability. 9. After the project is put into production, stay with the client for monitoring purposes and remain prepared to change system design radically to accommodate improvements arising from the success of EFD in stimulating deeper levels of insight. It is these last minute changes that are often responsible for making the system the longest lasting success. 10. Other than the above concepts, EFD projects should use traditional PMBOK™ methodology (PMBOK 2004). Some © Journal of Enterprise Architecture – November 2008 PMBOK processes become simplified or change with Enterprise Focused Development, but there is good fundamental effectiveness in most of the PMBOK techniques. Currently, Enterprise Architecture and EFD (or other iterative methodologies) are missing from PMBOK and they should be added to it. Instead of a work breakdown structure (WBS), a "feature breakdown structure" should work better with EFD because it measures progress better and makes it easier for the client to communicate about the project. Progress using EFD can be very fast, while at the same time client satisfaction is improved as the client is never out of touch with the project. The larger and more complex the project is, the more likely EFD is to out perform conventional methodologies, Spiral or Agile. While there are many potential benefits in implementing EFD, some of the risks include: • • • Not having an experienced, effective data modeler that can translate business requirements into data tables Culture change barriers on the part of programmers and their managers Management interference EXAMPLE OF USING ENTERPRISEFOCUSED DEVELOPMENT In 1992 I was asked to write a personnel system for a state agency. Since this should have been a centralized system, I recommended that they use the state's centralized system, but in those days, the centralized system seemed to be the most disliked app in the state. I contacted many other state agencies hoping that they could share theirs with me. The other agencies intensely disliked the centralized system so much that they tried to write their own apps but the system requirements were so complex that they had to abandon theirs and use the state's centralized system. One agency paid a private company $500,000 to write their system but it also failed due to requirement complexity. During my conversations with the other agencies I saw the same, unhappy attitude about the centralized system and anger about being forced to use it. The strong emotions just poured over the phone line into my ears. 62 I was given no choice but to proceed, so I interviewed the clients and gathered all documents to obtain the requirements. Within a few days I completely modeled the data. Not having any modeling tools, I typed the table designs into text files and printed them onto about 300 small pieces of paper and spread them out onto a large table where I could move them around and document how they worked together. The tables and their relationship to each other represented a fully working model of the system. Next I built a simple menu screen with only a few working entries: Add An Exam, Edit An Exam, Delete An Exam, Find Exams, View Exams. Ghosted out were main branches of the system menu: Print Applicant Rankings, Schedule Exams, Print Certification Letters, etc. There was no code behind the ghosted out options. This allowed me to freely rearrange the menu items as more efficient menuing configurations came into focus. I asked the client to add a few test personnel exams. Immediately, it was discovered that what the client described as immutable business rules of how exams were named, were not so immutable. This forced me to change the table design early. At this point I realized how effectively Enterprise Focused Development flushed out problems early in the design phase and saved me from having them compounded at the end of the project. The menu screen was a perfect communication tool, allowing the client to communicate with me as to how to best fine-tune requirements, and for me to obtain confirmation that the project was on the right track. Seeing actual menu options greatly facilitated joint analysis of complex processes. Physically sitting alongside the client allowed me to study minor reactions regarding interface ease of use. This revealed opportunities to make the interface more intuitive or put online documentation regarding difficult issues at locations where future, untrained users would need it the most. The system ended up being so intuitive that only short online instructions were required and no user manual had to be created. Each iteration was a quick refocusing of the entire project to the continually refined client © Journal of Enterprise Architecture – November 2008 requirements eventually making the finished system highly likely to satisfy the client. In this way, many false directions were nipped in the bud and many unexpected improvements resulted from bringing the client in as partner during project development. Repeating the above process for every new feature, the personnel system was vetted every step of the way and completed very quickly. It was a complete success. How many large projects can you name, have gone into production fulfilling every detailed requirement, leaving the client completely satisfied? If government managers were forced to choose one thing to keep them awake thinking at night, this should be their choice. It is simply a waste of money not to include Enterprise Focused Development in IT development. Using the EFD method in this case provided many benefits, which are highlighted by comparing what occurred in areas of the project that used the traditional ‘Waterfall’ method with the use of EFD: 1. Time (a) Enterprise Focused Development - one Enterprise Focused developer completed the personnel system in two years. (b) Waterfall - The only other contestant that finished the project was the centralized state department team that had six programmers working on it for twenty years. 2. Scope (a) Enterprise Focused developer completed a fully automated personnel system. (b) The centralized state department team system was not fully automated. 3. Budget (a) Enterprise Focused Development $50,000 a year for one developer's salary for two years. (b) Waterfall - difficult to estimate, but at least ten times as much. (c) Private industry - $500,000, but project failed. 4. Quality (a) Enterprise Focused Development - A quality project was delivered without a single flaw. (b) Waterfall - difficult to use. 63 5. Risk (a) Enterprise Focused Development - no risk because client tested and approved every new feature daily. Financial expenditure was minimal. (b) Waterfall - very risky as all projects except one failed, wasting large sums of taxpayer money. 6. Client Satisfaction (a) Enterprise Focused Development - clients were extremely satisfied. (b) Waterfall - all projects failed, except the centralized state app, which all clients disliked so much, they tried to build their own. This is hopefully a useful example of how one developer using EFD methods out-performed a number of government teams, private industry and a whole state agency. It is revealing to have a head-to-head contest where all teams have the exact same requirements. But beyond this comparison of EFD to the Waterfall method, EFD also provides improvements that the Agile method cannot. I have been using the basic concepts of the EFD methodology since the 1980's but did not hear the term "Agile" until 2008 when reading about how it could have saved an expensive IT project from failure. I was interested to see descriptions of others using Agile, and some of the techniques and benefits closely matched my experience. I also found that there were criticisms with some actual Agile implementations that I hope my methods described above prevent. Regarding how Agile projects fail, I suspect that there are scalability problems and that there is a random quality to the programming that is prevented by the method I have described where a master data modeler maintains highly integrated data design, and the programmers merely flesh out the design. The agility in the methodology comes from strict and ongoing data normalization from a centralized source that responds instantly to any changes at any time in a way that most closely and successfully aligns the project to the client's mission. Updated data modeling by the project leader is the control center that keeps the project focused correctly. One other consideration from this example is that government currently issues requests for proposals (RFPs) that require the project be developed using Waterfall methodology, the most inefficient way imaginable. Especially for © Journal of Enterprise Architecture – November 2008 budget authorities, Waterfall creates an illusion of control. Accordingly, RFPs must be written so that requirements are not complete until prototyping with EFD. Requirements should be delivered multiple times after feature implementation, each time bringing the updated system into clearer focus. Budget authorities should remove Waterfall from their requirements. If an agency contracts out most IT projects, it should consider writing the contract so that vendors use EFD, that is, it includes iterative code builds in the requirements gathering stage so that vendors produce requirements multiple times. Traditional project managers have been trained to refrain from coding until requirements are written into stone, however as described above, this method causes projects to fail. In the case of contracted projects, vendors lose money because by following Waterfall methodology, clients end up with software they don't want and will not pay for. THE EFD RELATIONSHIP WITH BUSINESS ANALYSIS Data modelers/data architects have unique skills for conducting business analysis. They see how data configurations affect business processes that other disciplines understand from only a process viewpoint. I recall once hearing a data entry worker complain about an application limitation regarding an old mainframe system that I was not responsible for and had never worked on. From that one conversation I was able extrapolate that a table was omitted from the system design when it was built many years ago. I notified the application manager who told me that they just recently identified the problem and started designing the missing table. The application manager had 10 years to discover this but a data modeler has a type of x-ray vision that can quickly and effectively see the entire enterprise’s inner workings. This x-ray vision makes data modelers the most effective business process analysts in organizations because changes to systems that they recommend build enterprise and governmentwide interoperability. Data modeler based business process analysis requires a list of discovery points that give the data modeler a view of the enterprise so that they can discover opportunities in the same way as in the example above. The discovery point 64 list below provides a rough idea of what meetings to attend, what boards to sit on and what artifacts data modelers should regularly study. • • • • • • • • Pre-design, design, FSR, RFP, SPR and PIER stage for each new project ITIL problem database – look for patterns indicating needed data design updates Change Control Board – change brings enterprise interoperability opportunities. Now that resources are available to change a process, can the data modeler identify new opportunities such as removing business rules from code and moving them into tables? Trouble tickets – look for patterns indicating needed data design updates Client wish lists Executive meetings – think how to align IT with executives’ goals Other meetings: PMO, problem-solving meetings, user groups, BPM, BPI, process re-engineering studies, etc. Client and other organizational forums Enterprise planners then create a prioritized portfolio of business process improvement projects from the resulting data. Then tablerelated projects are modeled and implemented with EFD methodology as shown in figure 1 at the top of this article. Opportunity discovery data might also be useful to other disciplines, such as security or quality management. For example, quality management analysts could find quality control opportunities in the data and work with enterprise planners on ideas to enterprise quality management. THE EFD RELATIONSHIP WITH DATA MODELING The Importance of Correctly Designing Tables to Model Business/Data Processes There is a common thread in a vast number of business problems that most problem solvers cannot see. It is government's largest business problem: incomplete and incorrect table design. Tables model the business. They are the heart and soul of how IT enables government to fulfill its mission. Tables are the closest approximation © Journal of Enterprise Architecture – November 2008 to the organization's processes. When tables are not designed correctly, IT is out of sync with government's mission. This problem manifests itself daily in constantly changing disguises, keeping perplexed managers busy fixing seemingly different issues. How this happens is that badly designed tables, including tables failing to connect with their keys in data islands, force layers of bad programming code to form around them for decades, creating a never ending ripple effect extending to other computer systems where clients see the problem camouflaged as a lack of functionality in many areas of their business processes. Here's a common business example, let's say your spouse signed up for the household electricity account, and the monthly statements only show your spouse's name because there was no data field for additional names. If you needed to demonstrate residency by showing the electric bill, it would be impossible. A oneto-many field was required for this but the programmer only created a single field for account owner. Every phone call that made to the electric company requires an explanation that your home's electric bill is not in your name. Another example is the frustratingly slow medical care that soldiers serving in the 2003 Iraq war received at Walter Reed Army Medical Hospital. The medical care process could have been streamlined by improved table design allowing for better data sharing between the Defense Department and Veteran Affairs (GAO, 2007). Besides the small group of people in the data modeling field, most people cannot recognize the commonality in the two disparate problems above. Most business IT problems arise from this problem, severely limiting IT alignment to government's mission. The solution is for each government agency to create a position to function as a data architect focused exclusively on keeping data modeled correctly (Federal CIO Council, 2001). Modeling the data correctly must be broadly defined to include removing redundancy across all units of the organization such as envisioned by the business reference model and integrating related data with outside government organizations via the data reference model (OMB, 2003 and 2005). Enterprise Architecture 65 is not solely data normalization on steroids, but that is the main idea. The data architect's role goes to the heart of government IT problem resolution by focusing the strongest problem solver on the root cause of the biggest problem. It is important to define table modeling as the main tool for bringing IT into alignment with government's mission – in fact it should remain as a primary focus area. The definition of table modeling here is broad in that it involves harmonizing data with outside governmental organizations, sharing data and systems with those organizations, and bringing continuity to table analysis and table updates driven by business process analysis. Whenever a table is planned, created or changes, the data architect should review it for enterprise integration opportunities. This includes potential future projects, checking external organizations for integration potential and building in business intelligence during the design phase. Each time there is change, there is an opportunity to bring government's entire data one step closer to third normal form. Redundant table removal, SOA opportunities coming into focus, data harmonization and removing business rules from programming code and placing them into tables are some of the opportunities that change brings. Once business rules are out of programming code and in tables, they are de-siloed and available to be shared enterprise-wide. Legacy systems should be included because even when they are replaced, conversion will be far easier when their files are normalized. Also, maintenance headaches from these systems will be greatly reduced. This incremental method is also the least expensive approach. Following this process, IT will move towards what I call super-alignment to the organization's mission where IT can nimbly deliver new features and solve problems in the most efficient way. Super-alignment to the organization's mission is clearly possible because E.F. Codd's invention, the relational model for database management, which is based on relational algebra, brings data to efficiency perfection using easy-to-follow rules (Codd, 1971). Simply bringing organizational data into third normal form resolves business problems throughout the © Journal of Enterprise Architecture – November 2008 organization and improves IT alignment to the organization's mission in the most powerful and cost effective way. It is fortunate that such a simple, mathematically based solution is available to solve so many problems. Third normal form is smarter than programmers, analysts, managers and government. Implementing third normal form unthinkingly, blindly, yields more intelligent results than humans. Many times when making the slightest variance from strict normalization, I have been surprised to find that there was hidden value in the strict form and needed to go back and correct the table design. Data modeling is an invaluable tool that makes the EFD process immune to subjective bias and a core component of productivity process that was shown in Figure 1. REDUCING GOVERNMENT COST THROUGH ENTERPRISE FOCUSED DEVELOPMENT Projects using the EFD method could be much less expensive to develop and may provide much higher quality than current commercial products. Costs are reduced by savings in time and number of staff required to manage the project. EFD reduces staff costs by eliminating risk and requirements management work that is optimized by the iteration process. Each iterative adjustment of the project through EFD saves many hours of work and prevents costly errors. Savings multiply as iterations progress. In traditional methodologies, problems become evident during the Integration stage, usually too late to save the project from major cost and time overruns. Lower cost, higher quality, faster implementation, lower risk, client satisfaction... these are strong motivational factors for implementing EFD. Here is an additional EFD benefit: many failed projects should have never been conceived because they were based on flawed logic. EFD identifies and stops these problems much earlier than Waterfall methods, saving taxpayers money that would have been spent completing them and then finding out they had no value. A personal example that I can share is that in the 1980's a major and badly conceived project was ordered by one of the deans at a university that I worked at. He overruled me and the CIO, demanding that the urgent project go forward. To address this 66 problem, I didn't expend any resources on the project except to build a data entry module for the main table. Next I explained that stage two of the project was for the dean to begin data entry. Somehow he and his staff never had time for data entry on this urgent project and a few months later acknowledged that the project should be scrapped. Had I not involved him in the project design and testing, many hours would have been wasted completing a worthless project. EFD not only flushes out problems in valid projects, it also flushes out valueless projects that somehow make it too far into the project queue. EFD provides continuous realitybased vetting that outperforms other methodologies in saving taxpayers' money. Categorized by cost, there are three types of government IT projects that benefit by using the EFD methodology. (Assumption: projects with capital outlay over $500,000 require independent project management and reporting.) 1. Projects reducible to under $500,000. Projects over $500,000 have additional reporting and oversight requirements that greatly increase cost. Enterprise Focused Development reduces expenses so effectively that some projects that would have exceeded the $500,000 threshold now drop below it. If project cost can be reduced to under $500,000, then those additional oversight and reporting costs will not exist. Projects that have reduced costs enough to avoid independent project oversight, reporting, and other mandated overhead, will clearly demonstrate cost savings that can be accurately predicted. 2. Over $500,000. Very large cost savings are possible due to the principle that the larger the project is, the more likely Enterprise Focused Development is to out perform other methodologies. Time, scope, budget, risk and customer satisfaction are very likely to be fulfilled with Enterprise Focused Development. 3. Under $500,000. The smaller the project, the more likely it is that all project methodologies will succeed. Savings will still occur with Enterprise Focused Development in all project management areas: time, budget, scope, quality, client satisfaction and risk. Enterprise Focused Development will outperform other methodologies, but will be more valuable in the area of client © Journal of Enterprise Architecture – November 2008 satisfaction and building enterprise-wide interoperability than in budget, scope and time areas. The sheer number small projects have potential for great costs savings through EFD. Applied to all federal and state government, Enterprise Focused Development will save hundreds of millions of dollars directly, and additional savings will be gained because higher quality systems require much less maintenance and much less frequent rewriting. CONCLUSION The simple EFD implementation guide above is basically all that is needed. For big, complex projects, it simplifies the process down to manageable chunks focused to work together towards enterprise integration by a data modeler. EFD increases the data modeler’s authority within project development so that enterprise architecture is built faster, cheaper and with higher quality. The data modeling discipline is unparalleled for visualizing potential enterprise-wide interoperational connections hidden within the complexity of seemingly unrelated and vast government processes. Data modelers must be elevated to higher positions so that they can use their methodology to steer IT nimbly and reliably to government’s goals. AUTHOR BIOGRAPHY Alex Glaros currently works for state government and has over 24 years of experience working in information technology. He has originated several concepts to advance IT alignment with government goals including Enterprise Focused Development, and software applications designed to bring business people into enterprise architecture planning as full Alex can be partners with IT professionals. reached at [email protected] REFERENCES Boehm, B. (1998). “A Spiral Model of Software Development and Enhancement.” IEEE Computer, May 1998. 67 Codd, E. (1971). Further normalization of the data base relational model. In Courant Computer Science Symposium 6: Data Base Systems, Prentice-Hall, Englewood Cliffs, N.J., May 1971. Federal CIO Council (1999). Federal Enterprise Architecture Framework Version 1.1, US Chief Information Officers Council, September 1999. Federal CIO Council (2001). "A Practical guide to federal enterprise architecture", White Paper, Washington DC, 2001, available at http://www.gao.gov/bestpractices/bpeaguide.pdf. Office of Management and Budget - OMB (2005). The Federal Enterprise Architecture Program Management Office, “The Data Reference Model”, Version 2.0, 2005. © Journal of Enterprise Architecture – November 2008 Office of Management and Budget – OMB (2003). The Federal Enterprise Architecture Program Management Office, “The Business Reference Model” Version 2.0, 2003. Johnson, J. (2006). “My life is failure”. West Yarmouth, MA: The Standish Group, 2006. Project Management Institute (2004). PMBOK Guides, “A Guide To The Project Management Body Of Knowledge.” United States Government Accountability Office – GAO (2007). "Information Technology: VA and DOD Continue to Expand Sharing of Medical Information, but Still Lack Comprehensive Electronic Medical Records", GAO-08-207T, October 24, 2007. 68 Case Study FOCUSING ON DESIRED OUTCOMES TO FORMULATE A CUSTOMER-VALUED ENTERPRISE MANAGEMENT STRATEGY: A CASE STUDY By Tyson Brooks and Jeffrey Wallk ABSTRACT The objective of this case study is to determine a method that best supports strategy development through determining customer outcomes using an Enterprise Management Strategy. Customer outcomes are essential in formulating organizational strategies to allow organizations to be more competitive. Adapting Chatterjee’s core objectives theme, the Enterprise Management Strategy includes components such as interest, ideals, incentive, infrastructure/institution, culture, capabilities, needs, values, strategy, objectives and core capabilities. In order to achieve successful strategy, organizations must first understand the outcomes required from customers. IT and business professionals from numerous organizations completed a questionnaire and the results indicate that understanding customer outcomes, strategy and the implementation of strategy enhances overall strategic development. This study proposes an Enterprise Management Strategy which focuses on customer comprehension of outcomes for strategy development rather than focusing only on outcomes and objectives. KEYWORDS strategy, customer outcomes, management strategy, strategic development, stratagem INTRODUCTION In this era of rapid changes in global markets, information technology (IT) and the ubiquitous Internet, it is more important than ever to apply effective implementation principles to implement organizational strategy. Focusing on desired outcomes that customers value allows organizations not only to develop unique core capabilities for new business models, but also allows them to critically evaluate their current value chains before they become vulnerable to competitors who can deliver the same customer outcomes (Chatterjee, 1998). Since IT strategy is the process of defining the business and the game of business is all about delivering value: creating it and capturing it (Brandenburger and Nalebuff, 1995), organizations must ensure their strategy models are executed properly to address customer’s desired outcomes. When properly defined, customer’s outcomes are remarkably stable over time, even in turbulent markets, whereas solutions can age very quickly © Journal of Enterprise Architecture – November 2008 as new technologies and processes are developed (Killen et al., 2005). Customers are the primarily reason why organizations exist and the outcomes that customers value and desire need to be understood and established before strategy can be executed effectively (Johnson and Selnes, 2004). To establish clear linkage, outcomes need to drive business strategy for products, services, and operations (management and processes). Core capabilities, processes, and structure are needed to deliver the outcome which customer’s desire and value. This is the key to providing a framework to prioritize and implement changes to products, services and operations to achieve high performance implementation. This case study suggests the following Enterprise Management Strategy (see Figure 1 on the next page) as a means to understand customer outcomes for strategy development. To develop stratagem, comprehending customer outcomes through their interest, ideals, 69 incentive, infrastructure/institution, culture, capabilities, needs, values and strategy must be categorized and determined. The Customer, Objectives, Activities, Resource (COAR) Model proposed by Chatterjee (2005) helps recreate the process by which strategies are developed and not merely explain why a strategy succeeded after-the-fact. This model indicates that the core objective concept can be used by any company to develop better clarity about its strategy and avoid unnecessary risk (Chatterjee, 2005). Other empirical studies feature customer service performance, such as employee service performance and customer outcomes (Liao and Chuang, 2004), performance of the customer service process (Ray et al., 2005) and service quality, satisfaction and relationship-oriented outcomes (Shemwell et al., 1998). To date, no research directly addressed the customer comprehension, categorization and determination before strategic development. The objective of this case study is to unsubstantially emphasize the correlation between customer outcomes, strategy and strategy implementation. To perform such validation, a questionnaire was developed and analysis with SPSS was used to provide statistical support. CUSTOMER OUTCOMES AND STRATEGY IMPLEMENTATION A customer is defined as a stakeholder who makes use of or receives products/services from an individual or organization. The identification of a customer could be defined as an end-user (or consumer); middleman, retail, wholesaler, distributors), shareholder/employee (who expect stability growth and security) or government agency that requires compliance. As such, customer outcomes are defined by the jobs that they need to perform, the metrics that they used to assess their overall satisfaction with these jobs and the constraints that they need to overcome in performing their jobs. The products and services provided by organizations should be focused on helping customers with getting their jobs done right otherwise, customers will not value these organizations (Kaplan and Norton, 2006). The changes that organizations need to make should be in direct response to opportunities identified by using careful analysis of gaps in performance in their products and services in meeting the customer valued outcomes (Meyer and Schwager, 2007). Once organizations establish a working methodology for identifying these opportunities and prioritizing them, then implementation management is straightforward. Govindarajan and Trimble (2004) suggest that by applying strategic innovation, organizations can then move out of the theoretical and into the practical application. Business and technology leaders can then addresses the opportunity gaps in meeting external customer outcomes for products, services and internal customer outcomes for operations (management and processes). By understanding this, organizations that can systematically improve customer outcomes can take important measures to improve their business models to increase their overall performance. Figure 2. Enterprise Management Strategy © Journal of Enterprise Architecture – November 2008 70 Customer outcomes, in general, allow organizations to be innovative and creative to reconfigure their value chains, and in doing so they deliver more value to customers at the same or lower cost (Chatterjee, 2005). Organizations with a deep customer focus excel at offering the outcomes each customer seeks (Vandermerwe, 2004). Most organizations must begin by redefining their markets in terms of customer service activities and customer outcomes instead of products and services (Sawhney et al., 2004). Through such practices, organizations will have a better commitment to customer outcomes. By reflecting their strategies and business models around outcomes, the organization will have a more realistic approach to services, make more efficient use of resources and more likely be successful in the future. Figure 2, Strategic Implementation Cycle, represents a high level view of how customer outcomes are manifested and implemented in organizations regardless of industry (note, this is a partial adaptation from NASA’s Strategic Management Process (for more information http://www.hq.nasa.gov/office/codez/strahand/pr ocess.htm). Most organizations understand this in part, but do not implement it in whole. Successful organizations have a good understanding of strategy development and have a proven framework for implementation. However, very few have taken the time to model changes using a formal design and architecture approach. Most fall into “best practices” offered up by the various think tanks and vendors. The problem is that these best practices will not lead to the differentiation and overall business agility that organizations are trying to achieve. They are inaccurate in that they are not built around an architected business model which focuses on customer outcomes. Focusing on outcomes which customer’s value is important because in today’s unpredictable business environment, strategic implementation is important (Day, 2006). One problem organizations face is that most strategic management models do not address customer outcomes and only focus on external and internal environmental needs as displayed in Figure 3 on the next page. Customers seek outcomes from products and/or services, and organizations must structure their © Journal of Enterprise Architecture – November 2008 strategies and business models to achieve them. For instance, purchasers of computer systems may want “a reasonable computer” but may desire “higher performance productivity”; internet users may “want to access the internet” but also want “speed and performance in retrieving information”. These outcomes become the basis for defining the quality of the customer experience and contribute directly to positive customer outcomes (Sawhney et al., 2004). Figure 2. Strategic Implementation Cycle Once customer outcomes have been defined, the establishment of a business vision for the products and services to deliver those outcomes has to be developed. That vision is merely an endpoint but can be a problem for implementing strategy. Implementation of strategy runs parallel to the corporate strategy development and is also driven by customer outcomes. Implementation aligns the idea pipeline with the strategic roadmap to help push the organization forward on its way to achieving its vision. The business strategy must not be translated into the tactical changes that are needed to implement within the product and service roadmaps along with changes to the organization (business units, management structure), and operational processes that are used to turn strategy into 71 implementation (Bleistein et al., 2005). This is a critical step to ensure that common pitfalls are avoided where each business area goes off and iterates their budgets and submit a list of projects that are derived from a stove-pipe perspective. Another problem is the actual implementation of strategy. The implementation of strategy will increase the risk and likelihood of success for an organization. Because the problem with implementing strategy is that there is uncertainty associated with moving between steady states (i.e. operations and maintenance of IT systems) when implementing strategy, it could be difficult to measure progress and estimate costs, time and effort (Croteau et al., 2001). In order to efficiently measure success once a steady state is reached, organizations must manage multiple changes at the same time and prioritizing change since the return on investment (ROI) around strategic change is not always clear. INTEREST, IDEALS, INCENTIVE, INFRASTRUCTURE. INSTITUTION, CULTURE, CAPABILITIES, NEEDS, VALUES AND STRATEGY (I4C2NVS) Strategy is about designing an organizations ideal future through interactive planning (Ackoff et al., 2006). In other words, organizations use strategy to be different by deliberately choosing a different set of activities to deliver a unique mix of value (Porter, 1996). Chatterjee (2005) suggests that strategy is used to provide customer outcomes as an output (product and services) that customers desire while focusing on theses outcomes instead of the means to deliver it provides multiple business models. Figure 3. Strategic Management Model (Adapted from Wheelen and Hunger (2004) © Journal of Enterprise Architecture – November 2008 72 Every organization utilizes some form of strategy through its business model and value chain activities to deliver goods and services (Walters and Lancaster, 2000). Strategy is of great interest to business and IT professionals because they are primarily responsible for implementing strategies to ensure the value from it. The ability to sustain strategic value is the ultimate goal of any strategy (Fréry, 2006). Assuming the linkage between customer’s valued outcomes and strategy exist; I4C2NVS is the key for achieving success based on how an organization implements its strategy to move forward to achieve its vision and goals. Therefore, we developed this strategy to demonstrate how customer outcomes have influence on business strategy as shown in Figure 4, Customer Outcomes and Strategy Linkage. In our framework, we sought to make explicit that it is important to understand customers’ competition and trading partners through their I4C2NVS before business strategy development and implementation are performed. Figure 4. Customer Outcomes and Strategy Linkage The foundational methodology of I4C2NVS can be explained as follows: Interest: First, it’s imperative to understand your customer’s interest. Understanding customer interest indicates importance to the customer and allows products/services to be more customer focused. Customer's interest should come first, while not excluding those of all other stakeholders such as owners, managers, and employees, in order to develop a long-term profitable enterprise (Deshpande et al., 1993). Ideals: Customer ideals are needed for new products and those for development which seem to offer the most promise from the organization's point of view (Hippel, 1978). By understanding these ideas, information for services of existing products and understood and information on how customers perceive products and the organization in the marketplace are captured. Incentives: Customer incentives for products and services should be understood due to the fact that customer’s could also use potential © Journal of Enterprise Architecture – November 2008 competitors. From the customer’s viewpoint, organizations should offer opportunities for rebates/discounts to retain services and increase performance. Incentives are distinct causes of inefficiency and should be managed as such (Tsay, 1999). Infrastructure/Institution: Understanding customer’s infrastructure/institution provides insight on how the organization can work through understanding its internal business processes, information technology (IT) capabilities and infrastructure. Thus, it’s important to understand the organizing logic for applications, data and infrastructure technologies, as captured in a set of policies and technical choices, intended to enable the organization’s business strategy (Ross, 2003). Culture: Customer culture defines all the processes needed to create customer value, from how to obtain customer understanding, how to develop, produce and deliver offerings to meet the customer needs, how to evaluate and 73 select appropriate channels to market, how to set value-based prices and secure payment, obtain customer feedback and improve customer value (Allen, 2004). • • • • Capabilities: Customer capabilities require that the organization has the resources, knowledge and means for the product or service being supplied to customers. These capabilities must be identified through which the internal and external aspects of value production processes for an organization can be integrated and coordinated (Möller, 2006). Needs: The identification of customer needs must determine which target markets the organization can serve best and be able to design appropriate products, services, and programs to serve these markets. The critical task for management is to create an organization capable of infusing products with irresistible functionality or, better yet, creating products that customers need but have not yet even imagined (Prahalad and Hamel, 2003). Values: Understanding customer values allow organizations to be able to match customer value opportunities with their capabilities precisely because they drive the structure of the marketplace (Carrillat et al., 2004). By understanding what customer’s value, organizations are able to provide products and services to meet those solutions with their own capabilities. Strategy: Finally, by comprehending customer strategy, organizations are able to link specific performance metrics to dependency relationships in their strategic plans to provide the ability to assess the performance impact of changes. To develop and understand customer strategy, you need to start by asking a deceptively simple question: Who is your target customer? (Rigby et al., 2003). With this emphasis on I4C2NVS, most organizations have a better focus on their strategies and required capabilities in terms of identifying customer desired outcomes instead of products and services. The contribution of this multilevel perspective for organizations is twofold: (1) customer outcomes drive business strategy which drives implementation which delivers desired outcomes and (2) understanding customer desired outcomes first establishes the need to develop strategic goals, core capabilities and initiatives to guarantee that the organization can attain achievement and continued existence. By providing a more stable and actionable view of the organization with strategy, the implementation of the strategy © Journal of Enterprise Architecture – November 2008 drives the foundation for delivering the desired outcomes. Customer Outcome Categorization: Analyzing Customer Core Needs As Figure 4 illustrates, because customer needs change and because change is all about moving from one steady state to another steady state, determining organizational strategy must first begin in a state of analyzing customer core needs and categorizing those needs. As the customer needs and values are analyzed from their I4C2NVS, the requirements are evaluated for comprehension. When the desires reach an expected state of completeness, it moves to formal development of desired outcomes (specifically products and/or services) for acceptance. Once accepted, the outcomes become the influence for the development of the organizations business strategy. During this initial phase, customer (both internal and external) needs/desires are gathered via numerous communication methods (i.e. surveys, interviews, questionnaires, etc.). Since these needs undergo frequent and rapid change, they need to be evaluated before they become formal. Change management must be used during this phase to control how change is governed and executed to ensure the needs are adequately achieved. It is inappropriate to develop strategies to only address the existing needs since the needs have not been formally developed to identify specific products and/or services. However, this phase of development comprises a significant work effort which would be quite costly to lose. Therefore, a determination should be made as to when to place the identified needs under the formal development phase. Since constant change at this stage is informal, it is the responsibility of management to use prudent judgment and professional practice to address the specific needs of focus for formative development. Customer Outcome Determination: Formative Development of Desired Outcomes (Products and/or Services) During this phase, the desired outcomes are translated into products and/or services (note that the actual products and/or services to address desired outcomes begin in this phase). As the outcomes are developed, changes are 74 made until the product and/or services reach an expected state of completeness. Once complete, the products and/or services should address all identified outcomes. The outcomes addressed by the products and/or services should then identify initiatives that contribute directly to the organizations strategies. At the close of the formative development phase, each desired outcome reaches a stage where it represents a complete product and/or service and should now influence the organization’s strategic planning process. Organizations will have a better commitment to address customer outcomes from this phase. By developing their strategic initiatives around outcomes, the organization will have a more realistic approach to develop products and/or services, making more efficient use of resources while helping the organization understand itself, its structure and its operating environment. CASE STUDY The proposed case study model illustrated in Figure 1 is a schematic representation of the principal research question: Can organizations develop and implement business strategies by understanding and analyzing customer outcomes? This case study is designed to support the understanding about an organization’s strategy development and implementation through customer outcomes. Data Collection An online questionnaire was conducted to gather information on how IT and business professional viewed customer outcomes, strategy and the implementation of strategy. One hundred and seventy business and IT professionals were identified as potential respondents who had the means (business acumen or IT experience) to participate. A total of 82 questionnaire respondents were completed and usable for our analysis, giving a response rate of 49%. More than half of the respondents (73%) were from the USA with 12% being from Canada. The respondents were mainly from the healthcare, consulting or information technology industries. Questionnaire Structure The questionnaire was broken down in three separate nodes: customer outcomes, strategy © Journal of Enterprise Architecture – November 2008 and the implementation of strategy. The design of the questionnaire was to measure the factors that focus on customer outcomes, strategy and the implementation of strategy on organizational strategy development. The first aspect in the Enterprise Strategy Management model is to understand the unique outcomes that customer’s value and one of its attributes is the consideration of what that unique outcome entails. Then the IT and business professionals were asked to rank the questions in terms of the following options: • • • • • Strongly Agree Agree Neither Agree or Disagree Disagree Strongly Disagree An understanding of customer outcomes by IT and business professionals is relevant not only at managements level but also at operational levels. Likewise it is needed to know if that understanding is applied to all individuals within an organization. The analysis of the responses not only provides a measure of understanding for these areas. It also allows a comparison of the consistency of results at different organizational levels. These questions refer mainly to customer outcomes but also have an interaction with other factors like strategy and the implementation of strategy. The proposed questionnaire permits to identify the level of each factor and its consistency at customer outcomes, strategy and the implementation of strategy levels. The criteria with less factors can be then further analyzed to verify which practices inhibit the meaning of customer outcomes or if the problem is the lack of linking between the customer outcomes and strategic levels. The main contribution is assessing customer outcomes results to obtain in depth understanding within one organization rather than comparing the customer outcomes between several individuals and organizations, this may contribute to enhancing the current customer outcome theory. Data Analysis To investigate the recompense and confines of the proposed questionnaire, this was applied to IT and business professionals via the web. The questionnaire was applied to these professionals 75 at different organizational levels. To interpret the results for the case study the following step was carried out: • customer outcomes, strategy and the implementation of strategy, each node was used as a separate indicator of the construct. SPSS was chosen as the statistical model approach. Calculate the standard deviation, variance, Skewness and Kurtosis across the different nodes. Each question uses a five-point scale to validate the area of each factor. Hence, the descriptions obtained are quantified for the area that each question is addressing. From Tables 13, it could be observed the perception of each participant has regards to customer outcomes, strategy and the implementation of strategy through the different factors. The Skewness of results for each node shows positive measures of the asymmetry distribution (accept for the participants’ response excluding the customer outcome and strategy nodes displayed in Table 1 for the definition of a customer [-.210] and in Table 2 on the next page for the results of strategic analysis [-.468]). The standard error of Skewness for these nodes produce normality of the data since the ratio of .266 is produced for all participants and the distribution is right-skewed. Results Skewness and Kurtois was used to assess the proposition of the case study to characterize the shape and symmetry of the distribution data. This model was tested by the simultaneous estimation of the measurement and theoretical (or structural) models, using the data from the 82 participant’s sampled to obtain range (R), sum (∑), mean ( ) with both statistics and standard errors, standard deviation (σ), variance ) and Skewness and Kurtosis both with ( statistics and standard errors. As the performance instrument used in this case study hypothesizes three dimensions, that is, The Kurtois for the majority of the data is positive (excluding minimizing cost [-.138] in Table 1, strategic planning [-.042] and results of strategic analysis [-.625] in Table 2) displaying that the observations cluster are more and have longer tails than those in normal distribution. The standard error of .526 again shows positive normality for Kurtosis indicating that the tails of the distribution are longer than those of a normal distribution. Std. Deviation Variance Std. Error Statistic Statistic Statistic Std. Error Statistic Std. Error 1.63 .068 .619 .383 -.210 .266 2.129 .526 134 1.63 .077 .694 .482 .410 .266 2.216 .526 4 143 1.74 .079 .717 .514 .218 .266 1.759 .526 82 5 157 1.91 .098 .892 .795 .599 .266 1.463 .526 82 4 124 1.51 .072 .653 .426 .364 .266 1.558 .526 Aligning Customer Outcomes With Investments 82 4 130 1.59 .081 .736 .542 .649 .266 1.602 .526 Outcomes Optimal Business Processes 82 4 133 1.62 .083 .748 .559 .569 .266 1.349 .526 Outcomes For Competitive Advantages 82 5 136 1.66 .092 .835 .697 1.111 .266 3.106 .526 Multiple Outcome Business Processes 82 4 122 1.49 .074 .671 .450 .548 .266 1.454 .526 Capturing Outcome Value 82 4 130 1.59 .078 .702 .493 .347 .266 .947 .526 Differentiating in Outcomes 82 4 134 1.63 .079 .712 .506 .247 .266 .819 .526 Evaluation of Business Models 82 4 117 1.43 .076 .685 .470 1.096 .266 3.212 .526 Differentiating Critical Outcomes 82 5 143 1.74 .102 .927 .860 .919 .266 1.394 .526 Minimizing Cost 82 3 121 1.48 .072 .652 .425 .229 .266 -.138 .526 N Range Sum Mean Statistic Statistic Statistic Statistic Customer Definition 82 4 134 Customer Identification 82 4 Customer Expectation 82 Addressing Core Outcomes Clear Understanding of Customer Outcomes Skewness Kurtosis Valid N (listwise) 82 Table 1. Customer Outcomes Descriptive Statistics © Journal of Enterprise Architecture – November 2008 76 N Range Sum Mean Std. Deviation Variance Skewness Kurtosis Statistic Statistic Statistic Statistic Std. Error Statistic Statistic Statistic Std. Error Statistic Std. Error Strategy Investment in Business Process Management 82 4 115 1.40 .081 .735 .540 .921 .266 2.448 .526 Modeling Organizational Structures and Business Processes 82 4 120 1.46 .087 .789 .622 .665 .266 1.403 .526 Strategic Investment in Technology 82 5 134 1.63 .096 .868 .753 .909 .266 2.655 .526 Effective Organizational Strategy 82 4 125 1.52 .076 .689 .475 .027 .266 1.247 .526 Strategic Planning 82 2 99 1.21 .059 .538 .290 .135 .266 -.042 .526 Results of Strategic Analysis 82 2 115 1.40 .067 .606 .367 -.468 .266 -.625 .526 Development of an Implementation Framework 82 4 109 1.33 .076 .686 .470 .879 .266 2.153 .526 Valid N (listwise) 82 Table 2. Strategy Descriptive Statistics Std. Deviation Variance Std. Error Statistic Statistic Statistic Std. Error Statistic Std. Error 1.21 .075 .680 .463 1.647 .266 5.657 .526 93 1.13 .064 .583 .340 1.516 .266 6.704 .526 4 106 1.29 .080 .728 .531 1.251 .266 3.431 .526 82 4 109 1.33 .085 .771 .594 1.342 .266 3.549 .526 Alignment of an Implementation Framework 82 4 107 1.30 .079 .715 .511 .930 .266 2.006 .526 Analysis of Existing Processes 82 3 99 1.21 .064 .582 .339 .332 .266 .522 .526 Process Reengineering for Execution 82 3 102 1.24 .071 .639 .409 .609 .266 .831 .526 Implementation of Strategy 82 3 99 1.21 .064 .582 .339 .332 .266 .522 .526 Valid N (listwise) 82 N Range Sum Mean Statistic Statistic Statistic Statistic Linking Strategy to Implementation 82 4 99 Implementation for Creating Core Business Objectives 82 4 Root Cause for Customers Need 82 Negative Recurrences Relating to Customer Outcomes Skewness Kurtosis Table 3. Implementation of Strategy Descriptive Statistics Thus, the results are good news in one sense. They suggest that improving strategy from customer outcomes should lead into the development of an implementation strategy and ultimately, an increased propensity to develop business strategy from this structure. The problem is that implementation of strategy is not easily implemented within organizations. That is, some organizations in many cases do not have enough knowledge, training, or skill to make the implementation of the strategy work (Coleman and Papp, 2006). In other organizations, the issue is much simpler because the level of © Journal of Enterprise Architecture – November 2008 maturity regarding strategy implementation can raise perceptions of execution management by making an actual improvement in product/service quality delivery. Discussion The focus of this case study was to support the development of an Enterprise Management Strategy. The study examined the integration between customer outcomes, strategy and the implementation of strategy and determined how individuals viewed their alignment. The proposition was confirmed and the co-alignment 77 of the three nodes did show clear impact on strategy development. Therefore, the case study findings confirm and support the theoretical underpinning of the Enterprise Management Strategy, namely that customer outcome, strategy and the implementation of strategy must be addressed during the planning process for strategic development. The concept of customer outcomes implies that there is an operational link between customer outcomes and strategy through internal coherence between the organizational strategic development and the actual delivery of the organizations capabilities on the other. Therefore, the findings indicate that all components of customer outcomes and strategy were set in such a way that participants must identify and relate these together to properly develop strategy. Organizations with advantageous organizational strategic development initiatives display characteristics which create value to organizations in terms of strategy development and innovation (Markides, 1997). Understanding customer outcomes makes possible the articulation of the organization’s strategic objectives. This comprehension encourages participation throughout the organization. Organizational flexibility is in response to organizational ability to change strategy and addresses customer outcomes. The case study results also indicate that effective understanding of customer outcomes have a high impact on business performance. By successfully implementing a strategy framework, an organization’s infrastructure can be developed to support demands from customer outcomes and having the necessary strategy in place to support. This strategy can be decomposed into an organizations underlying business architecture, which could support strategy and IT infrastructure requirements. By first determining which strategy should be implemented into the framework, and then comparing the organization’s existing architecture with the architecture required to support those business models, IT and business managers should be able to make more informed IT investments to support the architecture. Research Issues The case study method is not free of partiality. Indeed, one weakness of this case study is the use of the questionnaire approach. With a response rate of 49%, one must always wonder © Journal of Enterprise Architecture – November 2008 if the 51% non-participants were of the same opinion. It is, however, difficult to get a majority of CEOs and executive/senior strategist’s to participate in questionnaires, and while a higher response rate was sought-after it was hardly achievable. One example to be learned seems to be that the questionnaire should have been more representative of ideal strategic development situations. This would make the reporting of case study results less difficult, since it is not a standard procedure. Another limitation is improving the questionnaire instrument by eliciting proposed questions from executives prior to distribution. Elicitation would have allowed pre-selected respondents to add new proportions related to the topics before designing the final version of the questionnaire. Furthermore, this additional step could have contributed to explaining a greater percentage of the variance of strategic development. Overall, and relative to case study issues, it is concluded that SPSS is a great help to data analysis and elicitation through interviews can help conduct more valid and accurate research. CONCLUSION This case study contributes to current customer outcomes research by providing pragmatic findings regarding the functional linkage between customer outcomes, strategic and the implementation of strategy and supports the validity of the COAR Model proposed by Chatterjee (2005). While the customer outcomes have previously been examined, prior research has focused on other aspects of customer outcomes. For example, Shemwell et al. (1998) showed how customer outcomes and customer service relates to service quality, satisfaction and relationship-oriented outcomes while Liao and Chuang (2005) showed that customer outcomes are directly attributed to employee service performance and customer satisfaction. This case study contributes to the understanding of customer outcomes for strategy development by looking at it from an Enterprise Management Strategy perspective. It has identified that correlation should exist between customer outcomes and strategy development. Using a framework different from earlier research, this case study has identified a new strategy that should be further researched of if organizations are to succeed strategically. This case study also provides valid measurement of customer 78 outcome comprehension and its effect on business strategy development, using statistical tools such as SPSS used in IS research. As such, this case study provides avenues for further research in this field, including further examination of customer outcomes and strategy development. This could first be done by focusing more on I4C2NVS and the dimensions this approach seeks regarding strategy development. ACKNOWLEDGEMENT The authors would like to thank Dr. Reza Djavanshir from The Johns Hopkins University for comments, guidance and support on this manuscript. AUTHOR BIOGRAPHIES Tyson Brooks Tyson Brooks is a Certified Enterprise Architect (CEA) with BAE Systems Information Technology and has spent the last 11 years working on a wide range of consulting assignments covering Strategic Planning, Business Process/Reengineering, Enterprise Architecture and IT Investment and Capital Planning. Mr. Brooks received his Enterprise Architecture Certification from Carnegie Mellon University’s Institute for Software Research International (ISRI). Mr. Brooks has a Master of Science (MS) degree in Information and Telecommunications Systems from Johns Hopkins University, a Master of Business Administration (MBA) degree from Thomas More College and a Bachelor of Science (BS) in Business Administration/Management from Kentucky State University. Jeffrey Wallk Jeff Wallk is the Chief Architect at Hospira—a $4B Healthcare company supplying pharmaceuticals, injectables and devices to hospitals around the world. Mr. Wallk has worked there since 2006 outlining the future business and technical architectures as well as numerous projects with product development. Mr. Wallk has spent the last 1015 years with Fortune 1000 companies redesigning and rebuilding operations and infrastructures. Mr. Wallk earned his Master of Business Administration (MBA) from the Keller Graduate School of Management and his © Journal of Enterprise Architecture – November 2008 Bachelor of Science (BS) degree in Applied Mathematics from the University of Illinois (Urbana). REFERENCES Ackoff, R., Magidson, J., and Addison, H. (2006). Idealized Design: How to Dissolve Tomorrow's Crisis...Today. Wharton School Publishing. Allen, P. (2004). Customer Value Management: Five Steps to Creating Customer Value. PharmaChem [online], 2004, Retrieved July 24, 2007, from http://www.marketability.org/data/cvm_obtain_an d_improve.pdf. Bleistein, S., Cox, K., and Verner, J. (2005). Strategic Alignment in Requirements Analysis for Organizational IT: an Integrated Approach. 20th ACM Symposium on Applied Computing, track on Organisation Engineering – ACM SAC 2005. 2005. Santa Fe, USA: ACM. Brandenburger, A., and Nalebuff, B. (1995). The Right Game: Use Game Theory to Shape Strategy. Harvard Business Review, 76(3): 5771. Carrillat, F.A., Jaramillo, F., and Locander, W. (2004). Market-driving organizations: A Framework. Academy of Marketing Science Review [online], 2004 (5), Retrieved July 23, 2007, from http:// http://www.amsreview.org/articles/carrillat052004.pdf. Chatterjee, S. (1998). Delivering Desired Outcomes Efficiently: The Creative Key To Competitive Strategy. California Management Review, 40(2), 78-94. Chatterjee, S. (2005). Core Objectives: Clarity in Designing Strategy. California Management Review, 47(2), 33-49. Chatterjee, S. (2005). Failsafe Strategies: Profit and Grow From Risk That Others Avoid. Wharton School Publishing. Coleman, P., and Papp, R. (2006). Strategic Alignment: Analysis of Perspectives. Proceedings of the Southern Association for Information Systems Conference, Jacksonville, Florida, USA, 2006, 242-250 Croteau, A., Solomon, S., Raymond, L., and Bergeron, F. (2001). Organizational and Technological Infrastructures Alignment. 79 Presented at Proceedings of the 34th Annual Hawaii International Conference on System Sciences, 2001. Prahalad, C., and Hamel, G. (1990). The Core Competence of the Corporation. Harvard Business Review, 68(3), 79–91. Day, G. (2006). Aligning the Organization with the Market. Sloan Management Review, 41- 49. Ray, G., Muhanna, W., and Barney, J. (2005). Information Technology and the Performance of the Customer Service Process: A ResourceBased Analysis. MIS Quarterly, 29 (4), 625-642. Deshpande R., Farley, J., and Webster, F. (1993). Corporate Culture, Customer Orientation and Innovativeness in Japanese Firms: A Quadrant Analysis. Journal of Marketing, 57(1), 23-37. Fréry, F. (2006). The Fundamental Dimensions of Strategy. Sloan Management Review, 48 (1), 71-75. Govindarajan, V., and Trimble, C. (2004). Strategic Innovation and the Science of Learning. MIT Sloan Management Review, 45 (2), 67-75. Hippel, E. (1978). Successful Industrial Products from Customer Ideas. Journal of Marketing, 42 (1), 39-49. Johnson, M., and Selnes, F. (2004). Customer Portfolio Management: Towards a Dynamic Theory of Exchange Relationships. Journal of Marketing, 64 (2), 1-17. Kaplan, R., and Norton, D. (2006). How to Implement a New Strategy Without Disrupting Your Organization. Harvard Business Review, 84 (3), 100-109. Killen, C., Walker, M., Hunt, R. (2005). Strategic Planning Using QFD. International Journal of Quality & Reliability Management, 22(1), 17-29. Liao, H., and Chuang, A. (2004). A Multilevel Investigation of Factors Influencing Employee Service Performance and Customer Outcomes. Academy of Management Journal, 47, 41–58. Markides, C. (1997). Strategic Innovation. Sloan Management Review, 38, 9-23. Meyer, C., and Schwager, A. (2007). Understanding Customer Experience. Harvard Business Review, 85(2), 177-178. Ross, J. (2003). Creating a Strategic IT Architecture Competency: Learning in Stages. MIT Sloan School of Management, Working Paper No 4314-03, April 2003. Rigby, D., Reichheld, F., and Dawson, C. (2003). Winning customer loyalty is the key to a winning CRM strategy. Ivey Business Journal [online]. Retrieved July 23, 2007, from http://www.iveybusinessjournal.com/article.asp?i ntArticle_ID=409. Sawhney, M., Balasubramanian, S., and Krishnan, V. (2004). Creating Growth With Services. MIT Sloan Management Review, Winter, 34-43. Shemwell, D., Yavas, U., and Zeynep, B. (1998). Customer-Service Provider Relationships: an Empirical Test of a Model of Service Quality, Satisfaction and Relationship-Oriented Outcomes. International Journal of Service Industry Management, 9(2), 155-168. Tsay, A. 1999. Quantity-Flexibility Contract and Supplier-Customer Incentives. Management Science. 45(10), 1339-58. Vandermerwe, S. (2004). Achieving Deep Customer Focus. MIT Sloan Management Review, Spring, 26-34. Walters, D. and Lancaster, G. (2000). Implementing Value Net Strategy Through a Value Chain. Management Decision, 38 (3), 160-178. Wheelen, T. and Hunger, J., Concept in Strategic Management and Business Policy, 10th ed., Pearson Education, Inc., 2006. Porter, M. (1996). What is Strategy? Harvard Business Review, 74(6), 61–81. © Journal of Enterprise Architecture – November 2008 80 Carnegie Mellon University School of Computer Science Institute for Software Research International Enterprise Architecture Certification Training Certified Enterprise Architect Taught by Experienced Senior Architects On-Line, Classroom, and On-Site Courses Available Globally: $5,400 USD Total Cost * (*Price from January– August 2009) On-Line Curriculum: Two 12-Week Sessions Classroom Curriculum: Three 4-Day Sessions On-Site Curriculum – Customized to Your Needs Challenge Examination for Basic EA Course Now Available (Half of curriculum) $1,350 USD For additional program information or registration please email us at [email protected] or visit our website at http://strategic.isri.cmu.edu/v3/EATraining/overview.jsp Note: Some courses are taught by IBM/Telelogic, Inc. under license from CMU-ISRI. Course material is consistent in all classes. © Journal of Enterprise Architecture – November 2008 81