FEATURES
Editor‟s Welcome: John Gøtze
Architect‟s Spotlight: Kristian Hjort-Madsen ARTICLES
Re-thinking Enterprise Architecture using Systems and Complexity Approaches Sally Bean
Using Structural Performance Ratios to Guide Investments in Enterprise Architecture Chris Potts
Improve Cooperation and Alignment by Involving the Enterprise in the Architectural Development
Morten Gryning, Mikkel Mertz, Ambreen Khan, & Jan Staack Issues in Enterprise Architecture Value
Luis Silva Rodrigues and Luis Amaral
Services in DoDAF V2.0: Making Services Modelable and Relevant in DoDAF V2.0 Lawrence P. McCaskill & Andy D. Rogers
CASE STUDY
Enterprise Architecture and Information Technology Acquisition Management Russell S. Boyd & Samantha Geiger
BOOK REVIEW
Five Short Reviews of Five Short Books Len Fehskens
Journal of Enterprise Architecture
Chief Editor: John Gøtze, PhD, IT University of Copenhagen Associate Editors
Andy Blumenthal
CTO, Bureau of Alcohol, Tobacco, Firearms and Explosives
Haiping Luo, PhD
International Trade Administration, US Dept. of Commerce Tyson Brooks, PMP
School of Information Studies, Syracuse University
Stephen Marley, PhD Harris Corporation Dick Burk
Enterprise Architect
Thomas J. Mowbray, PhD TASC, Inc.
Larry DeBoever assureEV
George Paras
Managing Director, EADirections Gary Doucet
Treasury Board Secretariat, Government of Canada
Pallab Saha, PhD
Professor of Information Systems, National University of Singapore Robert Ellinger, PhD
Northrop Grumman Corporation
Cathy Sowell
President, Custom Enterprise Solutions, LLC Len Fehskens
VP, Skills and Capabilities, The Open Group
Torben Tambo
Associate Professor, Aarhus University Institute of Business & Technology John Grasso, PhD
School of Computer Science, Carnegie Mellon University
Michael Tiemann
Enterprise Architecture Consultant Kristian Hjort-Madsen, PhD
Chief Architect, Danish Ministry of Finance
Pat Turner
Director, Centre for EA & Research Management, Griffith University Michelle Kaarst-Brown, PhD
Associate Professor, Information Studies, Syracuse University
Tim Westbrock
Managing Director, EADirections Leon Kappelman, PhD
College of Business, University of North Texas
John Zachman ZIFA International William W. Krauter, PhD
Senior Architect, Lockheed Martin Corporation
About the Journal: The Journal of Enterprise Architecture (JEA) is a peer-reviewed international quarterly publication for the enterprise architecture community. Issues are published in February, April, August, and November each year. JEA supports global academic and practitioner communities of interest through the publication of articles that promote the profession of enterprise architecture, and deals with issues regarding practices and methods, case studies, and standards at the national and international levels. Note that the views expressed in JEA articles are those of the respective authors, and not necessarily those of the publisher, the editorial board, or the Association of Open Group Enterprise Architects (AOGEA).
Sponsors: JEA is sponsored by AOGEA (publisher), the Institute for Software Research International at Carnegie Mellon University, and the School of Information Studies at Syracuse University.
Copyright: All rights reserved. The reproduction, storage, or transmission of JEA articles or other content is prohibited without prior permission in writing from the JEA Chief Editor, who can be contacted via email at [email protected].
Article Submissions: Authors may submit properly formatted manuscripts to the JEA Chief Editor at [email protected] for peer- review and publication consideration. Author submission guidelines are available on the journal website at www.aeajournal.org.
Approximate timeframes from submission to publication for successful manuscripts are 6 to 12 months, depending on the backlog of previously accepted manuscripts. Copyright of all accepted articles and other published content is transferred by the author to JEA upon notification of acceptance by the JEA Chief Editor.
Subscriptions: One-year hardcopy subscriptions to JEA can be ordered for $80.00 (US) or $120.00 (International) per year or the electronic version for $50.00 (worldwide) through the JEA website at www.aeajournal.org and can be paid for online (Visa, MasterCard, or American Express). All subscriptions to JEA include a one-year membership in AOGEA.
Back Issues: All back issues are available in electronic form, and can be accessed online by subscribers. Libraries can apply for access by contacting AOGEA.
AOGEA Membership: Membership in AOGEA is automatically obtained and maintained through subscription to JEA. Each subscriber is assigned to the AOGEA Chapter that is nearest to that member, or to the global “At-Large Chapter”. Selection of AOGEA Chapter affiliation is made by the subscriber/member as part of the initial subscription and annual renewal process, done online at www.aeajournal.org.
Contents
Editor‟s Corner ... 4
Architect in the Spotlight ... 5
Re-thinking Enterprise Architecture using Systems and Complexity Approaches ... 7
Using Structural Performance Ratios to Guide Investments in Enterprise Architecture ... 14
Improve Cooperation and Alignment by Involving the Enterprise in the Architectural Development ... 19
Issues in Enterprise Architecture Value ... 27
Services in DoDAF V2.0: Making Services Modelable and Relevant in DoDAF V2.0 ... 33
Enterprise Architecture and Information Technology Acquisition Management ... 43
Five Short Reviews of Five Short Books: One Architect‟s Search for New Ways of Thinking about Enterprise Architecture ... 48
Editor’s Corner
By John Gøtze
This issue of the Journal of Enterprise Architecture (JEA) is coming to you from a new Chief Editor.
On behalf of the EA community, I would like to thank JEA‟s founder and now former Chief Editor, Dr Scott A.
Bernard, for all his hard work and perseverance in bringing us JEA, which has become better and better over the years, I think.
I would also like to thank Allen Brown and the AOGEA team for providing much-needed institutional support for its continued publication.
By taking on the role as Chief Editor, I realize that it will be a challenge to fill Dr Bernard‟s JEA-shoes. I will do my very best, and can only say that I am a passionate supporter of JEA‟s mission: to provide the EA community with a high-quality, peer-reviewed international quarterly publication. Essentially, JEA aims to support the global academic and practitioner communities of interest through publication of articles that advance and promote the profession of EA, and deals with issues regarding practices and methods, case studies, and standards at the national and international levels. I personally work in both the academic and the practitioner communities, and hope we together, across the communities, can make JEA a platform for the whole EA community.
We sincerely want to consult and listen to the EA community about the future direction of JEA, and will reach out to all interested in the near future. If you can‟t wait voicing your opinion, please do not hesitate to contact me at [email protected].
THIS ISSUE
The ambition for this issue has been to deliver a journal issue worthy of JEA as we know it. This means a collection of interesting articles written by competent people. I humbly think we have achieved this.
First up is Sally Bean, who suggests that we need to re- think EA using systems and complexity approaches. She is followed by Chris Potts, who suggests a way to guide investments in EA by looking into structural performance ratios. Morten Gryning, Mikkel Mertz, Ambreen Khan, and Jan Staack also look at re-thinking EA, and look into the utilization of Coherency Management to involve and embed employees in the architectural development. A shared theme across these articles is EA Value. Luis Silva Rodrigues and Luis Amaral want to investigate the EA Value theme further, and invite all enterprise architects to participate in a Delphi Survey. Changing the focus to a more specific EA situation, Lawrence P.
McCaskill and Andy D. Rogers present a methodology for making services modelable and relevant in DoDAF V2.0. This issue‟s Case Study is presented by Russell S.
Boyd and Samantha Geiger, and deals with a case where EA and IT Acquisition Management are implemented.
We will continue to bring you the classical features JEA has used. The Architect‟s Spotlight this time features Kristian Hjort-Madsen, chief architect in the Danish Ministry of Finance. Book Reviews is another feature, we will give priority to. In this issue, I have asked Len Fehskens to review five short books that enterprise architects should read.
EDITOR’S BIOGRAPHY
Dr. Gøtze is lecturer at Copenhagen Business School and at the Danish IT University, where he lectures and supervises projects in EA. He is co-founder of the Danish consultancy EA Fellows. He has served as enterprise architect at the National IT and Telecom Agency in Copenhagen, and participated in developing the Danish national policy for a government-wide enterprise architecture and interoperability framework.
He holds a PhD in Technology and a MSc in Engineering, both from the Technical University of Denmark.
Architect in the Spotlight
Dr. Kristian Hjort-Madsen
Chief Architect in the Danish Ministry of Finance
This section aims to bring recognition to a variety of contributors to the enterprise architecture (EA) field – from early pioneers, to current practitioners beginning their careers, to experts from other fields that influence EA – and is intended to show the rich diversity of backgrounds and views that the EA community enjoys.
Kristian is a chief advisor on e-Government to the Danish government and responsible for the unique all-of- government Danish reference models. He has been a board member in and secretary for a|EA International since 2005. In 2007, he also became the president of a|EA Denmark. In parallel to his jobs in the Ministry of Science, Technology and Innovation, and later in the Ministry of Finance, Kristian did his PhD at the IT University of Copenhagen, and defended it in June 2009. He holds a BSc in political science from Århus University and an MSc in software engineering from the IT University of Copenhagen. He has lived in the USA, Germany, Singapore, and Brazil and now lives in Copenhagen with his wife and two children.
IS THERE A DANISH WAY OF DOING EA?
All EA programs must be designed for a specific context.
Denmark has a strong cross-governmental collaboration culture and we have built our EA-program in this context.
I‟m not a fan of large and complex EA frameworks – in any sector. EA must provide just enough structure and guidance to bring the business and IT communities together for coherency. In Denmark we have bridged this traditional gap with all of our government reference models, a business reference model, and a service and technology reference model. These models span municipalities, regions, and the central government and we use them extensively for benchmarking, reviews of IT investments, service definitions for re-usable and sharable services, and semantic definitions across our public portals.
WHY THE FOCUS NOW ON REFERENCE MODELS?
In the early 00‟s we built a comprehensive EA framework and methodology for Danish e-Government. But adoption has been low and many agencies have found it difficult to understand the complexity. Thus, with the reference models we now pursue a more „lightweight‟
approach to EA. The shared taxonomies create a common language for business and IT to use when agencies are involved in the delivery of cross-agency services and it provides the Ministry of Finance and our
new shared service center for IT, Statens It, which was established in 2009, a framework for the cost-effective and timely delivery of IT services with standards, principles, and templates that assist in the design and delivery of IT capability.
The reference models are developed and maintained by a national editorial board with three FTEs representing the Danish municipalities, regions, and the central government. This setup provides a solid foundation for agencies to work from and a strong common language across the national e-Government program. We supplement the reference models with other tools from the EA toolbox. But, it is all about creating just enough structure and guidance – and not get too technically focused on frameworks and complex methodology.
WHAT IS THE NEXT BIG THING IN EA?
Fashions come and go. But, I think that EA programs should embrace and leverage social media platforms.
Since 2004 I have had my own blog (EAGov.com) and in the Ministry of Finance we recently launched a blog for the reference models with a Twitter profile. The new blogging tools were not launched to jump on the IT fashion bandwagon. We are using the new tools because we think the greatest economic value will come from finding ways to connect people that work with reference models or taxonomies inside or outside government. We use the new tools to get out of our comfort zone in the editorial boardroom and, hopefully, come up with creative new and innovative ways to use the reference models that generate more value with fewer resources in the interaction with our users.
Another trend that we are seeing in both private and public organizations in Denmark is that EA is moving out of the CIO office. Sitting in the Ministry of Finance, I am not part of the CIO office. I work in the Danish CFO office and talk more about coherency, performance management, and decision support information than I talk about applications and technology. EA is moving up the value chain helping the business align itself and the underlying IT-infrastructure – providing real business value by applying the rigor of EA to the business discussion. This is a really exciting development for the EA discipline. Something that we need to study further and encourage others to do.
WHAT'S IT LIKE BEING A PRACADEMIC?
I don‟t flash my PhD in the Danish government. Most of my colleagues don‟t know my academic background.
But, I think that my academic background has improved my „reflection on action‟ and „reflection in action‟ when I recapture my experience, think about it, mull it over, and evaluate it in our national EA program. JEA seeks to bridge the gap that tends to be between scientific and practical knowledge – and I think that is great!
Visit the JEA website at www.aeajournal.org
Call for Papers
The Journal of Enterprise Architecture is accepting article submissions for its 2011 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 Due Date
February November 1
May February 1
August May 1
November August 1
Please send articles to the JEA Editor at [email protected].
Author submission guidelines can be found on the a|EA website at www.aeajournal.org.
Article
Re-thinking Enterprise Architecture using Systems and Complexity Approaches
By Sally Bean
Abstract
This article looks at the issues currently confronting enterprise architects and the challenges posed when extending EA to be the architecture of the enterprise rather than just its information technology. It describes the contribution that Systems Practice and other disciplines can make to Enterprise Architecture (EA), and considers how the Cynefin sense-making framework can be used to help indicate which are the most appropriate types of approach.
Keywords
Enterprise Architecture, Architecture of the Enterprise, Sense-making
CURRENT STATE OF ENTERPRISE ARCHITECTURE Enterprise Architecture (EA) is a discipline that aspires to improve enterprise coherence, yet itself often seems rather incoherent, mainly due to the fact that it is still relatively immature. There is confusion over its meaning, purpose, and scope, and also the role of the EA function.
It‟s often unclear from reading current literature on EA whether an author is referring to a knowledge base, a process/practice, or a team of people. So it will be helpful to begin this article with a brief overview of the current state of EA, since opinions of what it actually is or should be are so diverse.
The majority of EA efforts to date have been directed at organizing IT systems (data, applications and systems software, and Infrastructure) from an enterprise-wide perspective, ensuring that these are consistent with business strategy and adaptable to change. EA is now increasingly being extended, with a greater focus on business architecture, since it is becoming difficult to separate business decisions from technology ones.
However, there are variations in the way that this extension is viewed. Some enterprise architects view business architecture as purely a descriptive tool for describing organizations in a structured way in order to provide a better context for IT exploitation and management, whereas others see it much more as a strategic design of the enterprise itself to improve efficiency, effectiveness, or innovation.
Most definitions of EA take enterprise to be an organization or business unit. In practice, EA techniques are often applied to the implementation of an endeavor;
i.e., a large program or project. Potts proposes that a definition of EA that makes more sense to executives ought to be more oriented towards the entrepreneurial meaning of enterprise, and suggests that EA should be about the creation of structural innovations (Potts 2010).
Both Potts and Graves assert that the scope of EA goes wider than the organization, and includes the „world‟
around the enterprise (Graves 2010).
There are usually three strands to EA activity, each of which may have business, information, and technology elements:
A prescriptive strand – determining, agreeing, and promulgating fundamental design principles, policies, and standards in support of organizational strategies, risk reduction, and key performance characteristics. These can then be applied to relevant decision-making in business/IT development projects.
A descriptive strand – creating an aligned set of formal models that define key elements of the business, its information systems, and its technologies and managing these in such a way that the relationships between these different elements can be clearly understood. These facilitate understanding of what is involved in business or IT change and can provide a common starting point for new business or IT development projects.
A programmatic strand – designing a target state architecture and identifying and coordinating the significant projects, commitments, and milestones to move towards it, including the development of core „building blocks‟ that can be shared across different projects.
Existing EA teams typically carry out blends of these three strands of activity with varying emphasis on business, information, applications, and technology architecture.
Overall coherence is achieved by the use of guiding principles and an EA framework. A formal approach to EA requires that such a framework is underpinned by an underlying metamodel that shows how all the different
© Journal of Enterprise Architecture – November 2010 elements of the framework are related to each other. A
less formal approach simply uses a framework as a classification tool to organize different types of knowledge artifacts that guide business and IT development.
The existing frameworks and methodologies for EA practice are generally very oriented towards the internals of EA content and processes and make it very difficult for business people to grasp how an EA approach will benefit them or their organization. The Zachman
framework has a clear logic to it which is easily grasped in theory but hardly any organizations have successfully managed to achieve the expected benefits of creating and exploiting Zachman-compliant models in practice.
The sequence of processes in the TOGAF ADM makes logical sense to an IT person, and can be mapped to IT planning and development lifecycles, but is more difficult to link into the normal processes of an enterprise.
This means that the practitioners in a typical EA team often struggle to demonstrate the value of their efforts.
They frequently fail to achieve the right degree of business involvement, may be out of touch with what‟s happening on the ground in project deliveries, and viewed as barriers to progress, rather than enablers of change. The standards and knowledge assets produced by EA teams may not be effectively promulgated and are not always appropriate or easily consumable by their intended audiences. Often several iterations of EA programs are required before an organization finds an approach that works for it.
Despite these difficulties, there is now good evidence that organizations can benefit from an effective approach to EA. Ross, Weill, and Robertson assert that such companies “have higher profitability, experience a faster time-to-market, and get more value from their IT investment” (Ross, Weill, Robertson 2006). Some EA groups are gaining increased influence in their organizations and using their EA knowledge bases and experience to help make more informed strategic decisions about business change as well as IT investment.
BUSINESS-ORIENTED ENTERPRISE ARCHITECTURE
The term „enterprise architecture‟ is somewhat misleading, since even those people who are part of a business-facing EA team are not actually designing enterprises; they are more likely to be acting in an advisory role and/or to be managing a repository of information. For example, a definition of EA recently produced by the Enterprise Architecture Research Forum in South Africa (EARF 2010) defines EA to be
“the continuous practice of describing the essential elements of a socio-technical organization, their
relationships to each other, and to the environment, in order to understand complexity and manage change”.
On the other hand, people who have been highly successful in designing or evolving enterprises are rarely or never termed „enterprise architects‟. Examples include Steve Jobs of Apple who has exploited the skills of designers in his organization and new business models to generate value from technologies invented by other people, and A.G. Lafley who embedded „Design Thinking‟ into P & G‟s way of working (Martin 2010) to focus more directly on the end consumer. Executives will generally turn to management consultancies when they need advice on business change design, rather than their EA team. However, the problem with many strategy consulting approaches to business change is that they are highly context-dependent – what works in one organization doesn‟t work in another, and they don‟t turn out to be particularly sustainable as learning is not retained. Additionally, top-down approaches do not take sufficient account of problems or opportunities at the working level, and this is becoming more of an issue as organizations become more networked and fragmented.
Many authors (e.g., Haeckel, 1999) have described the need for organizations to become more responsive, which means the ability to respond to changes in the environment without the overhead of costly transformational projects.
Establishing a role for an EA team whose remit goes beyond IT is a major piece of organizational design in its own right which needs to be considered in the context of this new, more networked world of business. This is fundamentally different from simply thinking of an EA team as a group of people providing services to the rest of the organization. It requires the organization to carefully examine its current business change capabilities and then explore the concept of EA; what it means, whether it‟s appropriate, how it might make a difference, and how it can best be positioned within the organization. This then needs to be revisited regularly in the light of experience.
In doing this, an organization should also recognize that there are many other fields that provide relevant knowledge in this area, which may need to be incorporated as part of an EA practice. Particularly relevant areas of interest are systems practice and complexity science. These offer a range of different ways of understanding organizations and proposing interventions for changing them, and will be discussed later on in this article.
The management of the EA discipline must take account of politics, power, and competing interests. The „value system‟ inherent in EA is generally seen as promoting the overall enterprise longer-term perspective over short- term local considerations, which creates resistance from
© Journal of Enterprise Architecture – November 2010
people who have different interests. It should be observed that this value judgment is not „baked‟ into EA which should really be more about creating a process where these types of trade-offs are evaluated and considered rationally to assess whether they are consistent with the organization‟s strategy and operating model and whether they are taking appropriate account of risks.
WHAT IS THE ESSENCE OF ENTERPRISE ARCHITECTURE?
As we have seen, current perspectives on EA are diverse. The author believes that a standard definition, acceptable to all, is unlikely to be developed in the near future and each organization will need to develop its own definition for its particular context.
While the overall heritage of EA is the domain of IT, there are different roots – such as software/ hardware architecture, and John Zachman‟s Framework, based on empirical observation of how large complex objects are engineered and constructed to meet the needs of a client owner. The danger with these engineering perspectives is that they don‟t take account of the human, behavioral dimension of organizations, and are predicated on an assumption that „order‟ is invariably a desirable quality of business. On the other hand, we should not lose the IT dimension of EA altogether, since information is crucial to enterprise performance.
As Morgan points out in his book Images of Organization (Morgan 1997): “mechanistically structured organizations have great difficulty adapting to changing circumstances because they are designed to achieve predetermined goals, they are not designed for innovation”. Morgan describes the strengths and weaknesses of other organizational metaphors, and shows how applying several metaphors in turn can help to generate insights while avoiding the traps and limitations of taking metaphorical views too far.
As long as one is mindful of the risk of over-extending metaphors, direct comparisons with building architecture can be useful and interesting. Insights can be drawn from the work of architects such as Christopher Alexander (1979) who has inspired much interest with his work on architectural patterns, and Stewart Brand, whose book How Buildings Learn (Brand 1994) describes how the architecture embodied in some buildings allows them to change and evolve gracefully over their lifetime. This can incorporate a more humanistic dimension, since architecture of buildings and to some extent, cities, is concerned with aspects such as context, purpose, meaning, conceptual integrity, style/aesthetics, as well as structure.
Most current EA practice does not address the social aspects of organizations, since the scope of the role has
been historically oriented more towards rational, ordered analysis of business issues. In their book Lost in Translation (Green & Bate 2008) point out the risks of this, and illustrate how their VPEC-T approach incorporates some social aspects of business change, by including the dimensions of Values and Trust in their analysis. Gartner have recently published a research paper on Hybrid Thinking (Gartner 2010), that is centered on human aspects of change and how they fit with EA and other similar practices.
Doucet et al (2009) consider the major goal of EA to be coherency management. They describe a progression of EA from Foundation Architecture (aligning IT with business goals) through Extended Architecture (co- designing business and IT change simultaneously in projects), to Embedded Architecture, where generically
„architectural‟ methods and ways of working are embedded in the normal processes of the organization and a level of coherence that is appropriate to the organization‟s culture and operating model is achieved and maintained organically.
What is a „generically architectural‟ way of working and is it always appropriate? What level of coherence is necessary in a given organization? While it is true that all too many employees and customers of businesses find them bewilderingly incoherent at times, a degree of diversity and unpredictability is also healthy in order to engender creativity and innovation.
The essence of architecture in an abstract sense can be summarized as follows:
A non-linear process of enquiry, exploration, and design
A clear understanding of context
A minimum subset of guiding principles required to achieve coherence, guiding design decisions with an eye on the future; knowing when to override them and how to manage the consequential risks
A set of models that enable visualization and exploration of different perspectives on the situation
The ability to differentiate areas of stability from areas of change
The ability to identify common patterns and ways of reproducing or avoiding them
An ultimate result that is pleasing and inspiring to the user and is capable of evolving gracefully over time
This list has much in common with the field of Systems Practice which has various methods to explore properties such as coherence. It might therefore be argued that EA can be thought of as „Systems Practice and Information Systems for the enterprise‟. This will be explored further in the next section.
© Journal of Enterprise Architecture – November 2010 APPLYING SYSTEMS AND COMPLEXITY-BASED
APPROACHES TO EA
EA and Systems Practice share modeling as a key activity, along with a number of other characteristics. A comprehensive treatment of the history of systems practice is beyond the scope of this article, but in essence, it is a collection of different ways of looking at phenomena or problems in a holistic way, as distinguished from the more common reductionist approach of logically breaking problems or situations down into constituent parts and working on them separately. Systems Practice values wholes over parts, emphasizes natural laws such as feedback and requisite variety, and uses a variety of models to understand inter- relationships and consider how situations are likely to evolve over time. In this context, the word „system‟ has a much wider meaning than „information‟ system or even a designed physical system like an aircraft, and refers to a
„way of looking at the world‟ in general.
Wilson gives a good example of this, relating to the program to produce the Concorde aircraft in the 1960s.
The aircraft itself was a designed physical system with a technical specification covering characteristics such as speed, capacity, and number of engines. However, as a human activity system, the Concorde program could be viewed as having a number of different purposes (each open to interpretation and discussion), including the obvious one of transporting passengers rapidly and the less obvious one of persuading the French to let Great Britain join the European Common Market (now the EU).
This example illustrates how methods of investigation need to be able to surface multiple viewpoints, worldviews, and perceptions and find accommodations between them.
The scope of Systems Practice is broader than EA and it can be applied to organizational units, or messy issues in any context. Like EA, Systems Practice is a discipline that draws on different traditions and approaches, and these approaches have themselves evolved over many years. Systems Practice in an organizational context usually involves the construction of a conceptual model which can be used in a number of ways:
To reason about conditions in the real world from a range of perspectives
To provide a reference model against which other architectural elements can be mapped
To provide a basis for planning information systems An example of this type of model being produced and used in an EA context is given by Bailey (2008). The Conant-Ashby theorem states that organizations cannot be effectively managed without such a model (Hoverstadt 2008). Note that the Systems Practice community is somewhat distinct from the „complexity‟
community, which has a different set of ways of looking at the world. These will be discussed later.
In the case of Systems Dynamics (Forrester 1961), the models represent the cause-effect and feedback loops that drive behavior in a non-linear way. Management cybernetics and the Viable System Model (Beer 1972) provides a means of looking at the ability of an organization to adapt to changes in its environment by recursively considering different types of activity, how they are related to each other, and assessing how to cope with variety. The Soft Systems Methodology (Checkland 1990) views systems thinking as an ongoing process of enquiry, using models of purposeful activity, and analysis of roles, norms, and values to structure a discussion that improves shared understanding of multiple perspectives on a problematic situation and actions to improve it. Value Network Analysis (Allee 2002) is a means of mapping tangible and intangible value creation among participants in an enterprise system.
There is an important distinction between ontological models of a reasonably well-understood domain that purport to represent parts of the „real world‟, and epistemological models that are used to explore perceptions of the real world (Checkland 2004).
Epistemological models are not necessarily models of reality but are designed to support discussion, debate, and argument about people‟s perceptions of reality, where the real nature of the problems to be tackled is unclear. As Hoverstadt (2008) points out, such a process can be very valuable, as otherwise, „mental models slide undetected into discussions and then dominate the way that managers think about their situation‟.
Soft Systems Methodology is based on an epistemological viewpoint, whereas Systems Dynamics models are more likely to be used for predicting outcomes, based on observations and assumptions about the real world. The Viable Systems Model tends to be associated with deterministic approaches but is amenable to an epistemological exploration as well, and is very useful as a diagnostic tool to identify areas where organizational cohesion and information system flows can be improved.
The utility of systems approaches is therefore highly dependent on selecting ones that are appropriate to the situation. The Cynefin Framework (Kurtz & Snowden 2003), which originates from Snowden‟s work in knowledge management but is informed by complexity science and is also applicable to strategy formulation, provides a means of exploring different organizational contexts and selecting approaches accordingly. Cynefin is a sense-making framework which allows people to better understand the contexts within which they are operating. It is based on the following systems typology,
© Journal of Enterprise Architecture – November 2010
where agents are anything that interacts with the system:
Ordered Systems are characterized by repeating relationships. Cause and effect are readily discoverable by empirical observation or other investigation. The nature of the system constrains the agent.
Chaotic Systems have no discernable relationship between cause and effect. Agents are
unconstrained and present in large numbers.
Complex Adaptive Systems exhibit no discernable relationship between cause and effect. Agents and system co-evolve. The result is a system that operates in far from equilibrium conditions and is inherently unpredictable.
Current EA practice (and indeed most management theory) is predicated on an assumption that organizations would be more effective if they exhibited a greater degree of order, but this may or may not be true in a rapidly changing world that is becoming more networked and diverse. Snowden (2009) points out that the nature of complex adaptive systems renders many current approaches to strategy and planning, where complicated and detailed plans are constructed, to be highly questionable. He also points out that overly constraining a complex adaptive system, treating it as if it were an ordered one, can lead to chaos.
The Cynefin framework illustrates the principle of bounded diversity; different tools and methods apply in different contexts. So if EA is to be successful as a discipline, its practitioners must recognize this phenomenon and adapt their practice accordingly. The framework is shown in Figure 1. It positions the above three types of system relative to each other with a further split of Ordered Systems into those which are Simple, where cause and effect are easily discernible, and those which are Complicated, where cause and effect can only be discovered by expert analysis. Figure 1 also includes recommended strategies for dealing with issues in each domain.
Snowden recommends the use of narrative capture techniques and safe-fail experiments to explore issues in the complex domain, where defined outcomes can‟t be identified and it is important to consult widely. Guiding principles may be appropriate to influence desired behaviors and discourage those that are undesired. He proposes that the value of the types of systems models described earlier will diminish as organizations become more networked and the level of complexity increases.
Note that Cynefin is a sense-making framework, not a categorization framework. It is intended to be socially constructed as an emergent property of people‟s interaction and discussion about factors and elements in a particular context. For this reason, there is a fifth
domain in the centre of the diagram, that of disorder, where people cannot agree on how something fits.
Figure 1: The Cynefin Framework
While it is true that use of narrative provides a rich human perspective on situations, it has been the author‟s experience that, even in the complex domain, simple epistemological models can be extremely powerful as a means of coalescing emergent ideas and helping to explore messy situations where there are lots of different viewpoints, missing information. or novel thoughts emerging. Such an exploration can expose different mental models and clarify a coherent path to move forward, often involving the identification and shaping of appropriate projects. Such ideas might include a complicated but bounded project that is more amenable to rational analysis and design or a set of safe-fail experimental projects.
It is possible to envisage pathways in time through the Cynefin space and create an evolutionary portfolio of projects. An organization might decide to explore a vague and complex business idea, such as customer relationship management, and begin by making observations and collecting narratives from customers and the people who deal with them to understand what customers really think about the organization and how employees relate to them. This might generate areas for further investigation, in the complex domain, to explore how information, resourcing, or other human issues inside the organization impact customers and their relationship with the organization. These could be carried out with VPEC-T or Value Network analysis.
Alternatively, the organization might decide to run some safe-fail trials of new ideas for products and services.
The narrative analysis might also identify some resourcing problems which could be analyzed by an expert with a more deterministic modeling tool – a complicated activity, or some operational problems with
© Journal of Enterprise Architecture – November 2010 a simple process that could be tackled with some
diagnostic activity.
Having developed a concept of what customer relationship management means for the organization (which could be explored and agreed using Soft Systems methodology), a project could then be established to acquire or build an information system to support it. This could involve a mixture of complex and complicated activity. All of this activity could be mapped against a capability model so that the impact on different parts of the organization can be assessed and any risks identified.
Johnston‟s paper (Johnston 2005) illustrates very clearly how the Cynefin model can be applied specifically to IT architecture. He points out that IT architects must understand and work with the forces of „Unorder‟ and also proposes that clear, concise IT system visions can help reinforce the development of desirable patterns.
This view of the value of a simple overall architecture diagram as a cohesion mechanism for the organization is reinforced by Ross, Weill, and Robertson with their recommendation that EA is encapsulated in a „Core Diagram‟ which is widely circulated.
FURTHER IMPLICATIONS OF THIS APPROACH EA must support an organization‟s requirement to adapt and innovate, as well as to execute. This article has proposed that, as an alternative to being someone who is concerned primarily with IT, a future role for enterprise architects in organizations could be to become facilitators of an evolutionary process of change through the application of systems and complexity approaches and the maintenance of models and other knowledge assets. They will design multi-disciplinary participative processes, drawing on external ideas and a wide range of skills from different parts of the enterprise to identify patterns of behavior, explore different mental models, and develop shared ones. They will develop a customized framework for managing and maintaining the strategic knowledge assets which are appropriate for the organization‟s context and maturity in EA. For this to be successful, the choice of knowledge assets must be carefully made, mindful of the effort required to maintain them, the importance of communicating them, and getting feedback. This needs to be treated as an iterative learning process, which evolves in the light of experience and changing priorities.
However, relatively few leaders in organizations today are thinking in this way, and all are facing different challenges. EA teams who want to adopt this way of working should:
Identify the organizational dynamics and issues that demand EA, rather than trying to „push‟ it at
sceptical executives.
Apply the approaches and principles described in this article to EA as a function itself, being very clear that it‟s a networked discipline that spreads beyond the core EA team, with executives
responsible for decision-making which is informed by EA activity, and subject matter experts
responsible for contributing to the activity and promulgating the results of it.
Be very flexible in their thinking and appreciative of other people‟s perspectives.
Be adept at demonstrating the value of this
approach with appropriate anecdotes and concrete examples.
AUTHOR BIOGRAPHY
Sally Bean is an independent Enterprise Architecture consultant. She advises large organizations in the private and public sector on how to develop their EA capability and embed EA approaches into their ways of working. She has over 15 years‟ experience in the field, with 10 years as a member of the EA team in British Airways. Here she championed many successful initiatives to exploit technology and share data and applications more effectively across the organization.
She also worked on the early stages of the Terminal 5 project and led a successful Architecture Community of Practice. She is particularly interested in systems thinking and complexity approaches and their applicability to EA.
REFERENCES
Alexander, Christopher (1979). The Timeless Way of Building. Oxford.
Allee, Verna (2003). The Future of Knowledge.
Butterworth-Heinemann.
Bailey I. White Paper: Using Soft Systems with MODAF 2008. Retrieved 30 Sep 2010 from website:
www.modelfutures.com.
Beer, Stafford (1972). Brain of the Firm. Wiley.
Brand, Stewart (1994). How Buildings Learn. Phoenix Illustrated.
Checkland, P. & Holwell, S (2004). Classic OR and Soft OR – an Asymmetric Complementarity. Published in Systems Modeling Theory and Practice. Wiley.
Checkland, P. & Scholes, J. (1990). Soft Systems Methodology in Action. Wiley.
Doucet, Gøtze, Saha, Bernard (2009). Coherency Management. iEAi.
EARF: Definition of EA as defined by EARF Retrieved
30 Sep 2010 from website:
http://hufee.meraka.org.za/Hufeesite/collaborations/earf/
definition-for-ea-as-defined-by-the-group.
© Journal of Enterprise Architecture – November 2010
Forrester J.W. (1961). Industrial Dynamics. MIT Press.
Gartner Group White Paper: Introducing Hybrid Thinking for Transformation, Innovation, and Strategy. Retrieved
30 Sep 2010 from website:
www.gartner.com/DisplayDocument?ref=clientFriendlyUr l&id=1352013.
Gorzynski, Bob & Snowden, Dave (Foreword) (2009).
The Strategic Mind, Management Books.
Graves, Tom (2008). Real Enterprise Architecture.
Tetradian.
Green, Nigel, Bate, C arl (2008). Lost in Translation.
Evolved Technologist Press.
Hoverstadt, Patrick (2008). The Fractal Organization.
Wiley.
Johnston, Andrew (2005). Masters of Order and Unorder. Retrieved 30 Sep 2010 from website:
www.agilearchitect.org/agile/articles/order%20and%20u norder.asp.
Kurtz, C.F.& Snowden, D.J. (2003). The New Dynamics of Strategy: Sense-making in a Complex and Complicated World. IBM Systems Journal, Volume 42, Number 3, 46. See also: www.cognitive-edge.com.
Morgan, G. (1997). Images of Organization. Sage.
Potts, Chris (2010). Presentation at EAC Europe: Driving Business Change with Enterprise Architecture.
TOGAF™ Version 9 (2009). The Open Group Architecture Framework. The Open Group:
www.opengroup.org.
Zachman, J.A. (2003). The Zachman™ Framework for Enterprise Architecture. A Primer for Enterprise Engineering and Manufacturing.
© Journal of Enterprise Architecture – November 2010
Article
Using Structural Performance Ratios to Guide Investments in Enterprise Architecture
By Chris Potts
Abstract
Measuring the structural performance of an enterprise offers essential insights into the strengths and weaknesses of its architecture. Executives and their Enterprise Architects need these measurements to guide and monitor their choices of where best to invest time, energy, and money in architectural innovations that enhance performance. Traditional approaches to Enterprise Architecture (EA) offer an abstract and overly-constraining view of its potential contribution to business performance, and of the options for achieving it. How does the Enterprise Architect move beyond these constraints, identify the most appropriate measures of structural performance, and choose the best practical and political interventions to ensure success?
Keywords
Enterprise, Architecture, Business, Performance, Knowledge, Structure, Measurement, Guiding Ratios, Executive, Communication, Collaboration, Innovation, Option, Investment, Enhancement, Change, Project, Constraint, Capital
INTRODUCTION
The purpose of Enterprise Architecture (EA) is to improve the performance of the enterprise (Bernard 2005). Traditional EA approaches are rich in frameworks and methods that are intended to support this purpose.
However, they fall short of practical guidance for EA practitioners (Enterprise Architects) in how to identify the specific measures of business performance that EA can most valuably influence. They also constrain the options for Enterprise Architects to work with others to improve those measures. Typically, the Enterprise Architect is guided to acquire, or produce, significant amounts of EA- related knowledge capital on the basis that it will be valuable, and to exploit it primarily in the context of projects. The Enterprise Architect can then find it difficult to establish, in their own minds and those of business leaders, the link between EA and actual business performance.
This article explores how to make this link using „EA Guiding Ratios‟, and how doing so can help both Enterprise Architects and executives invest their time, money, and energies in ways that create more value. EA can, as a result, enjoy more visibility and influence with senior management, so the article concludes with some political considerations of being a valued and influential Enterprise Architect.
ENTERPRISE ARCHITECTURE AND BUSINESS PERFORMANCE
In many organizations, formalized EA fails due to the perception that it lacks value (Forrester 2010).
Executives cannot see the link between business performance on the one hand, and the work of Enterprise Architects on the other. Yet the author‟s experience is that executives do see the value, in principle, of having a group of people who take a big- picture view of the enterprise, how it produces value, its current shape and structure, and how it could innovate structurally to perform better in future.
In any enterprise where the value of EA is not fully realized, it is the Enterprise Architect‟s responsibility to resolve this issue. At their disposal are traditional EA approaches, plus innovations that traditional approaches may not yet include and may remain beyond their intended scope.
Traditional approaches to EA are partly the reason for the gap between executives‟ belief that an architectural view of the enterprise must be valuable, and the value they perceive from EA. Those approaches commonly assume that the Enterprise Architect‟s contribution to enterprise performance is best supported by future-state visualizations of the company‟s structural and technological capital, or at least certain elements of that capital. They also consider this contribution is best achieved via interventions in the choice and execution of formal projects. For example:
“The enterprise architecture provides a long-term view of a company‟s processes, systems, and technologies so that individual projects can build capabilities – not just fulfill immediate needs.” (Ross et al 2006)
Assumptions such as these place major constraints on the potential for Enterprise Architects to communicate
and collaborate with executives, and to influence enterprise performance:
A company‟s performance depends on more than its structural and technological capital; in particular it depends on the enterprise of its people.
Processes, systems, and technologies comprise an incomplete view of a company‟s capital structure.
Such things can also be abstract or intangible to executives.
Although successful change projects contribute to business outcomes, much of an enterprise‟s performance comes from existing operations and informal changes.
Less than one-third of projects succeed. (Standish Group 2009)
EA interventions are not guided by the difference they can feasibly make to specific measures of business performance.
At the heart of the example above there is also a contradiction which has a significant impact on the success of EA: Enterprise Architects are persuaded to adopt a capital-centric focus, rather than an enterprise- centric one (Potts 2008). The following is another example of this contradiction, where the proposed route to success for EA is to focus on one specific aspect (in this case, processes) of the structural capital that the enterprise uses:
“The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.”
(TOGAF 9)
In practice, this contradiction applies both to the Enterprise Architect‟s view of the architectural landscape, and the work of EA itself. Much of the investment in EA can often go into the creation or acquisition of new knowledge capital, rather than into the enterprising use of EA-related experience and knowledge to improve measurable business performance. Furthermore, an enterprise and its executives are often missing the most crucial piece of EA knowledge: the measures of structural performance that are essential for guiding and monitoring architectural interventions and investments. These structural measures are different from operational measures, and can expose knowledge about the enterprise‟s strengths and vulnerabilities that operational measures will often miss.
STRUCTURAL VERSUS OPERATIONAL MEASURES Architecture is concerned with aesthetic appearance and structural performance. This article concentrates on the
latter. An Enterprise Architect‟s concern is therefore with the performance of the enterprise structure, rather than of the events that take place within it. Using the analogy of a theatre, for example, its architecture must be designed for the kinds of shows that take place there, but is not accountable for the artistic or financial success of the shows themselves.
Operational outcomes, such as top and bottom-line business value, are not architectural measures. Instead, the Enterprise Architect needs evidence of the extent to which the enterprise‟s architecture is designed to facilitate and encourage – and may also constrain – the production of value, rather than of the actual value produced. As will be shown later in this article, operational measures can, however, provide data from which evidence of structural performance can be derived.
Therefore, before deciding how best to influence an enterprise‟s performance, the Enterprise Architect must first choose what structural rather than operational measurements to use; observe how those measurements behave over time; and conclude what this means for future innovations and investments. With this knowledge to hand, the Enterprise Architect can then establish the best approach for influencing people‟s ideas, decisions, and actions, in ways that are valued and successful.
Experienced Enterprise Architects will discover these measurements through what Malcolm Gladwell (2005) called „thin slicing‟. Based on the recent history of an enterprise‟s corporate strategy, and on an understanding of its corporate culture, the experienced Enterprise Architect can rapidly conclude what structural strengths and weaknesses are likely to exist, and therefore which measures to establish first. Those with less experience must invest more time and energy exploring options and finding the answers, and they will usually benefit from mentoring.
For an enterprise that is more accustomed to using operational measures than structural ones, the latter can expose some new and unexpected knowledge. In particular, they yield insights into the enterprise‟s de facto strengths and weaknesses in structural design and investment. For executives, these insights can be both valuable and unsettling. As a result, once the Enterprise Architect‟s discovers the performance of the enterprise‟s de facto architecture, political skills will be at least as important as technical knowledge.
UNDERSTANDING THE DE FACTO ENTERPRISE ARCHITECTURE
Every enterprise has architecture, whether formalized or not. Because enterprises are composed of people, they can design, create, and change their own architecture.
Architecturally, this is the most significant difference between an enterprise and a building.
An enterprise that has never invested in any formalized EA will nonetheless have de facto architecture. If structural measures show that this architecture is performing well, then the Enterprise Architect‟s role and choices, and the enterprise‟s architectural investments, will be very different from a situation where the de facto architecture has material weaknesses.
Where does an enterprise‟s de facto architecture come from? It is mainly the product of two forces. The first of these is the gradual, often unnoticed, evolution over time, in which the architecture has improved or decayed as a byproduct of events and decisions that are not about the architecture per se, but have some influence over its shape and structure. The second, and more visible, force is represented by changes the enterprise knowingly invests in – many, but not all, of these are formalized strategies, programs, and projects. The skill of the EA practitioner is to influence both of these forces in ways that enhance the enterprise‟s structural performance, so that the combination of informal and formal EA is more valuable that the former on its own.
For the reasons already stated, if Enterprise Architects focus primarily on formalized projects, this will significantly constrain their potential influence on the very measures that provide the much-needed reflection of EA‟s value.
In any successful enterprise the Enterprise Architect‟s starting position must be that the de facto architecture is at least sufficient for whatever business is currently taking place within it. However, an Enterprise Architect that knows where to look will find evidence of the extent to which the de facto architecture, and the pattern of decisions that has created it, will continue to be sufficient for tomorrow‟s business ambitions and beyond.
MEASURING STRUCTURAL PERFORMANCE – AN EXAMPLE
There are many potential measures that an Enterprise Architect can use to explore, influence, and monitor an enterprise‟s structural performance. A valuable perspective to take is that of a potential investor in the enterprise, who is considering a medium or long-term stake in its success. Based on the evidence available, such as annual reports, how well is the enterprise structured to achieve future growth and returns? In this context, what are its strengths, to be protected and enhanced, and its apparent weaknesses, that will need to be addressed with innovations and investments?
An outside-in perspective of an enterprise‟s architecture, such as this one, is something that people inside the enterprise can find difficult to adopt. However, in architecture an outside-in view is vital for appreciating the contribution of the structure to the wider
environment. An inside-out view, while also valuable, cannot easily discern this contribution. For an Enterprise Architect, the ability to have both the outside-in and inside-out views of the enterprise‟s architecture is essential, and highly valuable to others within the enterprise.
A potential investor in an enterprise is likely to use ratios to explore structural performance, and how it has progressed over time. The Enterprise Architect should do the same, to discover the most valuable „Guiding Ratios‟ for EA. The following example uses one such ratio. It was calculated from data in the annual reports, published on the Internet, of a well-known global company. The identity of the company is not material, but at the time this data was analyzed it consisted of two main divisions. The annual reports gave the results for the company as a whole, and for each division. Eight years of data were available, which provided sufficient opportunity to observe progress over time.
The example ratio used here explores the structural productivity of the enterprise as the return (profit) it produces from each year‟s investment in operating expenses. For the enterprise as a whole (Figure 1), this ratio offers no obvious evidence of a pattern.
However, at the level of each division a different story emerges:
Division A (Figure 2) appears well structured to deliver year-on-year growth in its production of profit from operating expenses. The equivalent result from Division B (Figure 3) is, apparently, random. Based on just this one ratio, an EA practitioner can conclude that the potential contribution of formalized EA to the success of each Division is likely to be very different. For Division A, the EA strategy must be to maintain and develop the growth in structural productivity, whereas for Division B it must first be to achieve stability in its structural performance, and then growth.
In practice, a single Guiding Ratio will not be enough, and the value of particular ratios differs between enterprises. Other examples that the author has used include: operating income per unit of staff expense; profit
per transaction; revenue per unit of operating expense;
operating expense per unit of revenue.
The last two examples listed above help to demonstrate one of the first choices that the Enterprise Architect faces in choosing the most appropriate Guiding Ratios for an enterprise. They are the same ratio, inverted: one is a productivity ratio; the other efficiency. In fact, all of the examples shown above, with the exception of the last one, are measures of productivity. They are primarily about how much value the enterprise is producing, rather than the level of resources needed to produce that value. The Enterprise Architect must decide the extent to which the structural performance of the enterprise will be expressed as productivity, or efficiency. Depending on this choice, very different priorities and behaviors will emerge. The most valuable consideration in making this initial choice is the extent to which the focus of the Chief Executive Officer‟s (CEO‟s) strategy is itself about productivity or efficiency.
While the selection of EA Guiding Ratios is different between enterprises, some consistent criteria can be used to help with selection and to validate the results:
Acknowledge the focus of the CEO‟s strategy
Structural, not operational
Identify both strengths and vulnerabilities in structural performance
Reflect aspects of the enterprise that are tangible and important to executives
Will be politically acceptable (although may require careful diplomacy)
THE POLITICS OF ENTERPRISE ARCHITECTURE An enterprise‟s structural performance is the result of decisions made by executives and managers, past and present. However, it will, understandably, be interpreted as a reflection of today‟s business leaders. Even if any gaps in performance resulted from the decisions and actions of people who have since left the enterprise, it is in today‟s leaders‟ hands to know about those gaps and to be acting upon that knowledge.
Some business leaders are more accustomed than others to thinking and acting architecturally. As a result, the Enterprise Architect may often find that the performance measures used to guide architectural decisions and investments are unknown to executives. If so, questions of when and how to introduce executives to those measures demand careful political judgment.
The author has witnessed Enterprise Architects both succeed and fail, politically. The most significant difference between these two outcomes seems to be how well Enterprise Architects can harness their natural passions for sharing EA-related knowledge with others, especially where the effective exploitation of that knowledge could have a significant impact on the enterprise‟s future success.
Politically, the same principle applies to the Enterprise Architect‟s Guiding Ratios as any other EA-related artifact. While the Enterprise Architect must make careful political judgments about when, or even if, to expose others to EA knowledge capital, there should be no constraints on his or her personal enterprise in exploiting that capital to improve the performance of the enterprise.
CONCLUSIONS
To eliminate the gap in executives‟ understanding of the value of EA, the Enterprise Architect starts by establishing measurements of the enterprise‟s structural performance that can then be used to guide architectural decisions and investments (EA Guiding Ratios). These measurements are different from operational measurements, although may be drawn from the same data. To choose them, the Enterprise Architect‟s best practice is to adopt the perspective of a potential investor in the longer-term value of the enterprise.
With EA Guiding Ratios to hand, Enterprise Architects can decide how best to invest their own time and energies in developing further EA knowledge capital, or in active interventions that will enhance enterprise performance. These interventions are bound to include communication and collaboration with the enterprise leaders. Because some of these leaders may be less familiar than others with thinking architecturally, and because the Guiding Ratios are a reflection of executive