Your SlideShare is downloading. ×
Article
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Article

775
views

Published on

Published in: Business, News & Politics

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
775
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Article Coherency Management: Using Enterprise Architecture for Alignment, Agility, and Assurance By Gary Doucet, John Gøtze, Pallab Saha, Scott Bernard ABSTRACT This paper represents a significant point of evolution in thought and practice about the design and management of complex enterprises that often exist in highly dynamic, sometimes chaotic operating environments. The paper asserts that Coherency Management is the primary outcome goal of Enterprise Architecture (EA); that the architecture of enterprises should be formalized and promote coherency; and the best way to do this is to adopt 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. The paper discusses three modes of EA, namely Foundation Architecture, Extended Architecture and Embedded Architecture, that represent progression in thought and practice, with emphasis that the modes are independent but not necessarily mutually exclusive. The paper also discusses how collectively these influence enterprise coherency. The paper concludes by elaborating the ways and approaches to assess organizational coherence. KEYWORDS alignment, agility, assurance, change management, coherence, enterprise architecture, governance, organization design, risk management, strategy, transformation INTRODUCTION This paper represents a significant point of We see Coherency Management as the most evolution in thought and practice about the influential and important outcome of EA. This design and management of complex enterprises approach to EA is about more than technology that often exist in highly dynamic, sometimes as it now has strategic and business chaotic operating environments. The concept of dimensions, all of which must align to create Coherency Management is about using agility and assurance in promoting Enterprise Architecture (EA) to advance transformation and delivering value. EA is still a alignment, agility, and assurance in large, young and still evolving management discipline complex organizations. The essence of this that now includes all dimensions of an enterprise concept is that the architecture of enterprises and therefore is uniquely able to serve as the should be formalized and promote “meta” approach for designing and/or re- coherency, and the best way to do this is to designing enterprises to successfully compete in adopt EA as the ongoing, overarching method highly dynamic public and private sector for abstracting, analyzing, designing, and re- environments. The term "enterprise" can engineering new and existing enterprises- address many areas of systematic and regardless of the market, industry, or purposeful human activity, but in this context the government sector the enterprise belongs to. word most often refers to an enterprise, parts of an enterprise, or a group of enterprises. © Journal of Enterprise Architecture – May 2008 1
  • 2. The term "architecture", when used in the • Assurance - a term that addresses control, context of abstracting the enterprise to identify and a concept that speaks to confidence scope, function and relationships includes the and fidelity in the sources and use of frameworks, methods and artifacts enterprise products and services, as well as that describe the design and function of the resources that create them. enterprises in current and future states, and is often implemented at the enterprise, business While alignment, agility, and assurance are the unit, service, and system levels in a outcomes of managing coherence, the means consistent manner, which allows for for achieving this is the use of EA as a decomposition and aggregation. EA has the methodology. Figure 1 below shows these potential to align strategy, business, and relationships. technology elements across the entire enterprise, and can provide the context and standards for implementing a number of industry and government best practices including strategic planning, capital planning, service- oriented architecture, information technology infrastructure libraries, knowledge management, program management, security controls, internal controls, quality management and human capital management (Bernard, 2005; Saha, 2007). We use coherence as a term that speaks to a logical, orderly, and consistent relation of parts to the whole. The paper uses this term as a central theme, which is appropriate and necessary in presenting ideas about how to design and operate complex enterprises that must continually adapt to changes in mission Figure 1. Coherency Management and market conditions. Coherency management has three fundamental UNDERSTANDING outcomes: ENTERPRISE ARCHITECTURE • Alignment - a term that addresses the need In the final section of their book Enterprise for similarity in EA methods at all Architecture as Strategy, authors Ross, Weill levels/areas of the architecture, and an and Robertson state that “Enterprise important concept for complex enterprises Architecture (EA) in many companies refers to a that are composed of a number of lines of detailed blueprint of systems, data and business and business functions technology (Ross et al., 2006). It is now clear that have competing priorities and limited that EA is instead a business vision. EA begins resources. at the top – with a statement of how an enterprise operates – and results in a foundation • Agility - a term that addresses an of IT and business process capabilities on which enterprise's ability to manage change, and a it builds its competitiveness.” EA continues to concept that is an essential element for the evolve and mature as an area of theory and survival of enterprises that have to operate practice. It continues to influence a number of in dynamic environments where change is management and technology areas and constant and windows for important disciplines, directly and indirectly. opportunities now open and close in hours, days, and weeks; and customer Metaphorically, an EA is to an organization’s expectations are driven by increasing operations and systems as a set of blueprints is choices in providers and access to best-of- to a building. As IT departments build systems, breed service delivery; as well as new they create legacies based on business technologies that improve many facets of assumptions that might no longer hold true. By every day life. following an architecture-based approach to © Journal of Enterprise Architecture – May 2008 2
  • 3. systems development, organizations strive to consequence greater sustainability of the EA address several IT issues. Though EA is often program, and assumed to follow business strategy, to align IT with business’s strategic objectives, increasingly • Active participation by individual functions and departments and contribution to overall evidence of business strategies depending on IT enterprise-wide architecture is critical to the capabilities are also surfacing. Defining, success of the EA program. describing and deploying EA is a large and complex undertaking that allows enterprises to: EA is not just about creating good (1) understand business operations and uncover documentation artifacts. Good artifacts serve no deeply embedded business rules, (2) elevate the purpose if not utilized. That is in fact the bane of role of information within the organization and EA currently. EA is about good governance and treat it as a core asset, (3) understand gaps a disciplined approach. As far as artifacts are between information needs of the business and concerned, our take is leverage on what you information provided by IT systems, (4) create already do or produce. What enterprises need to synergies between available and stable ensure is that the artifacts serve the objectives technologies and emerging technologies, and (with minimal adaptation). Hence any (5) leverage technologies to discover and take structure/format/rules in creating artifacts should advantage of new business opportunities. These be used as soft guidelines, not prescriptions. in turn allow organizations to be more agile What EA provides is a unifying and alignment when need arises. mechanism focused towards a common vision for the enterprise. Enterprise Architecture provides significant business benefits to many types of enterprises, We see that today EA is highly isolated, many of which demonstrate a high degree of detached, and disconnected from the rest of the capability and discipline in areas such enterprise (with the exception of IT department). as strategic planning, policy design and The primary reason for the disconnectedness is execution, technology planning and that most (if not all) EA programs are still driven standardization, knowledge and data by the CIO / IT Department (Gøtze & management, enterprise integration, program Christiansen, 2007). In such situations the management, service management, portfolio credibility of the IT department (and its management, and system development life perceived role in the enterprise) is a critical cycle management. Many of these best factor in characterizing the EA program. As a practices also embody and contain a number result current EA tends to eventually reduce of critical success factors for the enterprise itself to Enterprise IT Architecture, at times with (Gøtze & Östberg, 2007). Despite incorporating a strong business focus. We envisage EA being best practices, many enterprises still allow key much more than that, and that is what this paper business units to define their own priorities, is all about. workflow, standards, and budgets, which often lead to ‘silo’ or ‘stovepipe’ programs, services, and systems within and between the business A plethora of practices and programs often leads units. It is clearly evident that this approach to confusion, resentment and cynicism to leads to sub-optimization in the enterprise anything new, EA included. Typical response in as the full benefit of common standards and such scenarios includes furious efforts to collaboration opportunities are not realized measure and demonstrate the value of EA across the enterprise. Advancing the current EA programs. It is also typical for EA programs not body of knowledge and state of practice is to be tightly coupled to other relevant imperative because: management practices. The positioning of and linkages to and from EA vis-à-vis other relevant • Many current EA programs are primarily upstream and downstream management driven by the IT / IS department. practices need to be accomplished following careful analyses of current and future practices. • EA is often reduces to IT centric architecture and hence relegated as ‘yet another technology initiative’. The EA process is not restricted to "transformation". If EA is done only when • Organizational levers lead to higher degree something else tells that the enterprise needs to of management attention and as a change then EA will never tell when the © Journal of Enterprise Architecture – May 2008 3
  • 4. enterprise needs to change. EA is inherently The authors advocate the use of EA to promote designed as a strategic management tool that the coherent management of enterprises. Since allows organizations to realize the Integrated the introduction of early EA concepts by Enterprise Life Cycle. The approach taken is to John Zachman in the late 1980's (Zachman, weave in EA and position it within existing 1989), this discipline has evolved into three management practices and leverage upon them primary modes of being practiced: instead of designing the EA program as a Foundation Architecture; Extended Architecture, separate line of activity. This approach allows and Embedded Architecture. Balanced enterprises to maintain linkages between their Architecture is a term that is used in this paper respective functional strategies and plans. to describe when an enterprise utilizes the best However as an enhancement, the EA layer and the most appropriate characteristics of each between corporate strategy and implementation of the three modes of EA. The authors believe facilitates common standards, requirements, that no organization has yet reached a level of principles and effective governance and control maturity in their EA program, so as to have a (not limited to IT alone). EA is intended to allow truly balanced architecture state. With this enterprises to move towards shallower ‘silos’ paper, we intend to influence EA thinking and and seek greater collaboration opportunities. practice over the next decade. Internally within an enterprise, leveraging on other management practices not only ensures To illustrate the three modes, let us first consider continuity and sustainability in the EA program, an enterprise that is new to EA. This scenario is but also tighter vertical and horizontal alignment. depicted in Figure 2 below. Figure 2. Enterprise Architecture Not Applied to an Enterprise Even without EA, the enterprise exists, and is business. The Foundation Architecture can be operational. It does business, and it has IT. But seen in the most widely accepted definition of it does not manage enterprise-wide coherency. EA provided by Ross, Weill and Robertson It performs badly when it comes to alignment, where “EA is defined as the organizing logic for agility and assurance. Now, considering that the an organization’s core business processes and enterprise "adds" EA into the equation. IT capabilities captured in a set of policies and technical choices, to achieve business Foundation Architecture standardization and integration requirements of The most common and 'traditional' and classical the firm’s operating model”. Figure 3 on the next EA is what we call Foundation Architecture. The page depicts the Foundation Architecture EA is most often done to align IT to the graphically along with its primary purpose. © Journal of Enterprise Architecture – May 2008 4
  • 5. Figure 3. Foundation Architecture – Aligning Business and IT Within Foundation Architecture there are two United States’ Federal Enterprise Architecture levels of maturity. The first level is where the (FEA) is a good example of Foundation organization’s IT architecture is documented for Architecture. Designed to fulfill the requirements the entire enterprise in its current and future of the Clinger-Cohen Act of 1996, the FEA is states. The focus is on well-architected, well- primarily a CIO / IT department centric program designed IT systems with enterprise-level (Saha, 2008). The agencies are mandated to alignment, interoperability, and efficiency. develop and communicate their respective EA to Accordingly, this level of Foundation the Office of Management and Budget for the Architecture is very IT-centric, and for many purposes of justifying IT budgets. This enterprises EA is still viewed as this type of data represents the control mechanism built within and technology architecture, just that it is being the EA program to realize architecture implemented at the enterprise level. This governance. perspective does help to leverage concepts such as federated patterns, but under-delivers Extended Architecture from an enterprise-wide strategy and business The concepts of Extended Architecture came perspective. about in the late 1990’s and focused on engineering an entire enterprise from and At the second level of maturity, in addition integrated strategy, business, and technology to providing descriptions of IT systems across perspectives. It is an expanded view to the the enterprise, the business of the enterprise is earlier described Foundation Architecture. To captured in a standardized and consistent support this expanded view of EA, a number of manner. This well understood business approaches and tools were developed to provide description then forms the input and provides standardized, repeatable methods for describing the context for well designed IT systems and an enterprise in all dimensions - beyond just the applications. The value of EA is measured IT perspective. Whereas Foundation according to the success of investments in IT Architecture used architecture methods and and their alignment to business requirements. tools to capture business requirements in order to design better IT systems, in the When done properly 'Foundation' EA provides extended approach architecture methods and excellent value to enterprise and even with the tools capture strategic goals and related other ways to be discussed, there will always be business requirements in order to design the a place for this type of EA. Ross et al (2006) enterprise. Figure 4 on the next page depicts said that "Enterprise architecture results in a the Extended Architecture. foundation of information technology and business process capabilities on which a company builds its competitiveness." The © Journal of Enterprise Architecture – May 2008 5
  • 6. Figure 4. Extended Architecture – Driving Business Transformation The following represent illustrations of how are properly aligned to business goals and Extended Architecture uses architecture strategic direction. methods and tools to capture strategic goals and related business requirements in order to design An interesting example of Extended Architecture the enterprise. is the Canadian Government's Business • Line of business and program owners Transformation Enablement Program which, by use the Extended Architecture concepts to its very name, can be seen as a tool to help transform business units and services. program owners transform their business (Treasury Board of Canada, 2004). With the • Executives use Extended Architecture Extended approach, EA is recognized as a key to ensure consistency between policy change management tool and the EA instruments and to measure alignment organization (possibly distributed) provides between strategy, business, and technology greater and greater value to a growing number initiatives. of non-IT business functions. There are • Human Resources managers use Extended business level valuations of the EA program in Architecture to ensure that processes and addition to the Foundation measurement of products for managing human capital are successfully delivered IT. consistent, effective, and aligned. • IT managers use Extended Architecture to ensure that their systems and investments Figure 5. Embedded Architecture - For Designing and Managing the Enterprise © Journal of Enterprise Architecture – May 2008 6
  • 7. Embedded Architecture outcome logic model which every division In the Foundation and Extended modes of EA, leader / functional head can link in to). artifacts (various types of documentation) are • Public reporting uses terms and language created as the result of an EA process or which is consistent throughout the method, somewhat extraneous to the functioning enterprise. (e.g., services for youth can be enterprise. With Embedded EA architecture identified as such, costed consistently, and tools, methods, and models become embedded results determined consistently-whereas all in the normal (usually existing) processes of the process owners currently use their own day. Rather than relying on processes and categorization for their customers making people extraneous to the business programs aggregate analysis impossible). (and their processes), the architecture is produced by the processes themselves. In this Evaluation of the EA program becomes a matter way the architecture is organic and ever of assessing enterprise coherency. Embedded greened naturally, shown in Figure 5. Examples Architecture enables the greatest degree of of Embedded Architecture are: enterprise coherence but is admittedly a longer • Annual planning artifacts that road to travel. Ultimately more comprehensive employ architecturally aligned rules for how and holistic, but it takes much longer. It does not annual plans are expressed. That is, they mean enterprises cannot start because every follow the normative models (e.g. Reference single process brought into alignment brings a models) for expressing what the business degree of more coherence. To be truly on top of is about, their clients, goals, objectives, etc. the game enterprises, however, need to have all three modes of EA going on simultaneously. • All human resource artifacts are created according to EA rules. So organization A project or a program should not be the reason charts get refreshed regularly, when they do, to develop EA. The architecture should already they are expressed in a way that supports be there and be usable by the project. An enterprise wide views of roles and organization’s EA should be context neutral. responsibilities. Embedded Architecture demands that CFOs, • Artifacts from different processes are CTOs, Chief Planners, Chief Strategists, and HR interoperable to support cross-functional Managers, embed the EA discipline so that they decision support and business design. For produce well architected artifacts and as a example, process maps leverage EA product from their normal routine, not for the standards which allow them to be linked sake of the project. There are many acts, to job descriptions which, it turn link to policies, and procedures causing departments to organizational design artifacts and business file artifacts of every stripe but they do not have plans. With these types of linkages, an the necessary rules/constructs/ to be useful for analysis to determine the security generalized purposes. Rather than developing a implications of using an externally delivered new report, the embedded approach expects service can be made much more efficiently. enterprises to get the existing reports to be more • Web service catalogues which get updated multi-purpose. EA can be used to ensure with every release of on-line services and artifacts achieve higher degrees of reusability. are categorized according to the same The unintended benefit of coherent artifacts is models which define the annual budget. So the reduction of the reporting burden which a user can come to the web pages and be currently plagues many large enterprises today. profiled according to the same way services This mode of EA needs minimal additional are profiled and the services can be engagement mechanisms and the program is dynamically combined based on their fit. able to sustain itself. And just in case the users are curious they can see how much this service and/or all In the embedded approach the strategic goals services for their type of people cost on an drive business requirements, which drive annual basis. technology solutions. Here, not only is the level • Strategic planning uses the methods and of EA raised to include strategy, but the common language to ensure a holistic plan ubiquitous (organic) nature of the architecture is which aligns to all other key players in the acknowledged as well. The architecture of an planning arena. (e.g., strategic plan use enterprise exists in all dimensions, whether it is © Journal of Enterprise Architecture – May 2008 7
  • 8. acknowledged or not, and EA makes all aspects and practice is an accumulation of ideas and of the organic architecture explicit by formalizing methods that have come together to form a body the relationships between strategic, business, of knowledge that can be used to holistically and technology views across all operating units understand, optimize and create enterprises of with the ultimate intent of making better many types. The ideas captured in each of the enterprises. modes of EA can be viewed as independent, which are applicable to enterprises either alone or in combination. In other words, they are not THREE MODES OF mutually exclusive. Such advancement in EA ENTERPRISE ARCHITECTURE thinking, takes it to the next level of maturity. In One interesting aspect of the progression of EA some cases an attempt to rapidly implement this thought and practice is that it has largely been a multi-modal approach to EA programs can be process of accumulation, not replacement. This disruptive to enterprises. Indeed EA only has its means that the concepts about how to improve tremendous value when done properly. It is the the planning and implementation of IT systems opinion of the authors that EA researchers and that grew out of first way to do EA are still practitioners must do to themselves that which applicable and work well with the business they seek to do to others, that is, manage their design and integration concepts of the change and the change they introduce to the “Extended” mode. These also are critical enterprise with EA. Figure 6 below summarizes activities to advance the coherence needed in the modes of EA described above. The key the Embedded Architecture. Hence EA thought distinguishing characteristics are also depicted. Figure 6. Three Modes of Enterprise Architecture with their Distinguishing Characteristics © Journal of Enterprise Architecture – May 2008 8
  • 9. COHERENCY MANAGEMENT – AN top-down structured. There has been definite EMERGING MANAGEMENT PRACTICE shift towards ‘decentralized’ bottom-up structured enterprise. And more recently, the The idea of coherency and its management emergence of networked virtual / extended already has some traction in the business world. organizations has made the whole landscape Lissack & Roos (1999) wrote about coherent even more complicated. Usually in most actions, those actions that make sense to others enterprises, all three ‘types’ of organization in our organizations, and argued that managers models are visible concurrently in differing forms need to know how to promote and encourage and intensity. Coherence thus becomes an coherent actions throughout the organization. imperative, as it allows enterprises to govern in Our argument is that coherency management is an orchestrated manner. Figure 7 below depicts an increasingly important management practice, the components of coherency management which will need to be developed as a science- along with the three organizational models. based discipline. This is necessitated by the fact that enterprises no longer are just ‘traditional Figure 7. Coherency Management and Various Organizational Models As Hamel (2007) says, our enterprises have communication crisis' in our enterprises, and we "21st-century, Internet-enabled business know that enterprise architecture is going to processes, mid-20th-century management help, but how does coherency become an processes, all built atop 19th-century integral part of an enterprise's management management principles", and that "with a practice? battalion of new business challenges massing on the horizon", it is time for enterprises to "start We need to examine the ways in which we can taking management innovation as seriously as be coherent. Just as there are three modes of they take other sorts of innovation". Hamel here EA, there are three types of coherency an talks about Management 2.0 as an emerging enterprise needs to manage: management practice, and envisions Web-like organizational structures, which will be very 1. Coherent Rules for Descriptions: There is disruptive to the traditional information and just enough common language used in communication systems and practices. formulating the various descriptions and artifacts across the enterprise, to allow for So, we know that we have an 'information and coherently assembly and/or analysis. A common language for the enterprise is the © Journal of Enterprise Architecture – May 2008 9
  • 10. foundation for coherent descriptions. The In some ways, coherency could be considered 'Just Enough Rules' principle should be an element within a Risk Management applied. Rules can be constricting, so every Framework. For us, the critical thing is that we effort must be made to ensure that each rule all understand, talk about and deal with is really needed, not for the sake of coherency in a way that reduces its negative coherency, but because the added impact. Bring it out in the open and realize that coherency must deliver some value to the we have been dancing around the problem for enterprise. years without addressing it head on with a 2. Coherent Descriptions: The descriptions, science-based approach. Developing this once presented in comparable manner (i.e., measurement technique will be an important following the rules) can then be made success factor for Coherency Management. coherent. Processes can be optimized, polices can be harmonized, services can be For purposes of measuring coherency a designed for joined-up service delivery, etc. consistent basis of comparison is needed. The The methods for achieving this rely on the units of measurement will be called 'Coherence rules, but rules in this case are not enough. Objects'. They are the way we subdivide the There must be a structured approach to enterprise, project and/or investment so we can getting these done. If at all possible, the best compare apples to apples. Service Oriented place to start is by looking at the planning Architecture provides a best practice in this processes so that enterprise Vision, regard but it must be seen as way to subdivide Strategy, and Designs can be aligned first, the business of the enterprise, not just the hence setting the context for the evolution of systems. Granularity of these objects can be the coherent enterprise. quite different but the rule is that once defined, this way of looking at the enterprise must be 3. Coherent Enterprise: Here, the enterprise applied in all management processes experiences coherent operation and consistently. Maybe your classification scheme execution. The Enterprise is effective and results in comparisons at the business line level efficient and well understood. Alignment is (e.g. accounts payable), or perhaps it is finer very mature because the rules allow grained than that (e.g. invoice reconciliation), descriptions to be compared for alignment either way these Coherence Objects form the and adjusted accordingly. Agility is basis for your comparisons. The Reference achieved because of designs are coherent, Models of Enterprise Architecture are, in most which includes a developed understanding cases, the first discernable source of Coherence and practice of loose coupling by design Objects. instead of tight coupling by accident. Assurance is gained through an ability to not For each Coherence Object we can ask only have all the information but also, questions like: Is it aligned with the intent of through coherency, have the information similar investments? Are there any design gaps provide real knowledge. Knowledge that you or overlaps with any related investments? Is it are making the right decisions, designing the following applicable Rules (especially the rules right enterprise and executing at peak of description)? proficiency. The 'score' for coherency is determined by Logically, we foresee a fully operational system looking at these and other alignment type of Continuous Coherency Improvement, which questions. The evaluation will be difficult, includes a component of measurement. especially in the early implementations, but will become easier once more and more descriptions become consistent (i.e., follow the ASSESSING ENTERPRISE COHERENCE rules). How would one assess coherence in an The Coherency Assessment can be used to: enterprise? It is done by going to the heart of what coherency management is about: 1. Make project decisions. Go-No Go, Confirm a logical, orderly, and consistent relation of parts Design, Ensure Logistical Alignment, etc. to the whole. 2. Contribute to the knowledge of project coherency across the enterprise. The © Journal of Enterprise Architecture – May 2008 10
  • 11. individual scores can be prorated against engagements. Currently, Gary is the vice- the total project budget. president of the Association of Enterprise Architects, and the former President of the In our forthcoming book Coherency Canadian chapter. He is also Head of Management: Architecting the Enterprise for Delegation for Canada at UN/CEFACT where he Alignment, Agility and Assurance (fall 2008) we works with other countries on standards for will develop these ideas further. trade and business groups. For over 20 years Gary has been hands-on across the disciplines of Systems Development, Architecture, CONCLUDING THOUGHTS Engineering, and Management. He has been a part-time instructor of technology for several This paper introduced the idea of Coherency years, and holds a B.Sc. (Computer Science) Management, asserts that this is the primary from the University of New Brunswick. Gary can outcome goal of an enterprise's architecture, be reached at gary.doucet@rogers.com. and proposes that existing and new EA practices in the foundation, extended, and John Gøtze is an Associate Professor at the embedded areas should be used Copenhagen Business School and at the Danish synergistically to achieve coherence in complex IT University, where he lectures and supervises organizations. The focus on coherence requires projects in EA. He currently serves as President that an EA extend beyond technology solutions of the Association of Enterprise Architects and business requirements, to include the (a|EA). He is co-founder of the Danish think-tank strategic goals that drive the enterprise. Like EA Fellows. He has served as enterprise Occam's Razor, the value proposition of architect at the National IT and Telecom Agency coherence management is that it is helpful to in Copenhagen, and participated in developing stakeholders when complex entities are made the Danish national policy for a government- simpler and therefore are more wide enterprise architecture and interoperability understandable. Managing coherence through framework that included a service-oriented EA promotes alignment, agility, and assurance architecture. In the EU IDA program, he was which make the enterprise more capable and involved with developing the European competitive. Interoperability Framework under the eEurope 2005 program. As a civil servant, Dr. Gøtze co- We foresee the evolution of Coherency authored several Danish and Swedish official Management into a critical function of corporate policy documents, including the White Paper on and public sector management. There will be EA in Government and The 24/7 Agency: clear, measurable, and obtainable targets. There Criteria for 24/7 Agencies in the Networked will be a program of continuous improvement for Public Administration. He holds a PhD in coherency and Enterprise Architecture will be Technology and a M.Sc. in Engineering, both the cornerstone of the Coherent Enterprise. from the Technical University of Denmark. John can be reached at john@gotzespace.dk. AUTHOR BIOGRAPHIES Pallab Saha is a member of the faculty at the National University of Singapore and teaches Gary Doucet is the Chief Architect for the courses on EA, IT Governance, and Business Government of Canada. Leading the Enterprise Process Management at the post-graduate and Architecture and Standards Division (EASD) senior executive levels. His current consulting within the Chief Information Office (CIO) Branch engagements are on developing EA for of the Treasury Board Secretariat, he is Singapore Government agencies. Dr. Saha is a responsible for the advancing Enterprise frequently invited speaker at international and Architecture (EA) within the Federal local conferences on EA and IT Governance Government. Gary came to the Government of (including several keynote sessions). He is the Canada from CGI, a leading provider of end-to- primary author of the Enterprise Architecture end information technology and business Methodology and Toolkit for the Government of process services, where he was a Director of Singapore. He is also a contributing author and Consulting Services and instituted a Solutions an editor of the Enterprise Architecture Management Office to ensure a consistent Management Guide being developed by a|EA. approach to solutions across their client Prior to academia; he was instrumental in © Journal of Enterprise Architecture – May 2008 11
  • 12. managing Baxter's environmental health and Journal of Enterprise Architecture. Volume 3, safety offshore development centre in Bangalore Number 1. as Head of Projects and Development. He Gøtze, J. and Östberg, O. (2007). authored the Handbook of Enterprise Systems Interoperability, Change, and Architecture. ICA Architecture in Practice and has completed his Study Group Report. International Council for second book Advances in Government Information Technology in Government Enterprise Architecture. He holds a Ph.D. in Administration. Information Systems from the Indian Institute of Science; an MBA from Utkal University; and a Hamel, G. (2007). The Future of Management. B.Sc. in Electronics from Bangalore University. Boston, MA: Harvard Business School Press. Pallab can be reached at pallab@nus.edu.sg. IFIP-IFAC Task Force (1999). GERAM: Generalized Enterprise Reference Architecture Scott Bernard is currently the Deputy CIO at and Methodology, IFIP-IFAC Task Force on the Federal Railroad Administration, the editor of Architectures for Enterprise Integration, Version the Journal of Enterprise Architecture, a member 1.6.3, (March). of the faculty at Syracuse University, and also Lissack, M. and Roos, J. (1999). The Next teaches at Carnegie Mellon University. He Common Sense - Mastering Corporate wrote the first textbook on EA: "An Introduction Complexity Through Coherence. New York, NY: to Enterprise Architecture" and developed the Nicholas Brearley Publishing. "EA3 Cube Framework" and the "Living Morabito, J., Sack, I. and Bhate, A. (1999). Enterprise" EA web portal design. He has over Organization Modeling: Innovative Architectures 20 years of experience in IT management, st including work in the academic, government, for the 21 Century. Upper Saddle River, NJ: military, and private sectors. He’s held positions Prentice Hall PTR. as a CIO, management consultant, line-of- Ross, J., Weill, P., and Robertson, D. (2006). business manager, network operations Enterprise Architecture as Strategy. Boston, MA: manager, telecommunications manager, and Harvard Business School Press. project manager for several major IT systems Saha, P. (2006). A Real Options Perspective to installations. He has developed enterprise Enterprise Architecture as an Investment architectures for public, private, and military Activity. Journal of Enterprise Architecture, organizations, started an EA practice for an IT Volume 2, Number 3. management consulting firm, developed his own consulting practice, and taught EA at a number Saha, P. (2007). Handbook of Enterprise of universities, businesses, and agencies. He Systems Architecture in Practice. Hershey, PA: holds a Ph.D. in Public Administration from IGI Global Information Science Reference. Virginia Tech, a M.S. in IT management, a M.A. Saha, P. (2008). Advances in Government in business management, a B.S. in Psychology Enterprise Architecture. Hershey, PA: IGI Global from the University of Southern California, and a Information Science Reference. CIO Certificate from the U.S. National Defense Treasury Board of Canada (2004). Business University. Scott can be reached at Transformation Enablement Program. Retrieved sabernar@syr.edu. April 13, 2008, from http://www.tbs- sct.gc.ca/btep-pto/index_e.asp. BIBLIOGRAPHY United States Congress (1996). The Information Technology Management Reform Act of 1996 Bernard, S. (2005). An Introduction to (renamed the Clinger-Cohen Act). Public Law Enterprise Architecture. Second Edition. 104-106, Division E. Bloomington, IL: AuthorHouse. United States Federal Enterprise Architecture Bernard, S. (2006). Using Enterprise Program Management Office (2006). FEA Architecture to Integrate Strategy, Business, and Consolidated Reference Model, Version 2.0. Technology Planning. Journal of Enterprise Federal CIO Council. Architecture. Volume 2, Number 4. Zachman, J. (1989). A Framework for Gøtze, J. and Christiansen, E. (2007). Trends in Information Systems Architecture. IBM Systems Government Enterprise Architecture - Part 1. Journal. Volume 26, Number 3. © Journal of Enterprise Architecture – May 2008 12