• No results found

The Journal of Enterprise Architecture

N/A
N/A
Protected

Academic year: 2022

Share "The Journal of Enterprise Architecture "

Copied!
62
0
0

Loading.... (view fulltext now)

Full text

(1)

The Journal of Enterprise Architecture

February 2008

Volume 4, Number 1

Features

Editor’s Corner 2

a|EA Points of Contact 3

Architect’s Spotlight: Mike Lowe 4

Special Feature

Framework Standards – What’s It All About? 7

John Zachman

Articles

The Organization’s Compass – Enterprise Architecture 11

Soh Eng Kiat, Lim Han Chiew, Poon See Hong, and Chang Chai Fung

A Goal-Oriented Way to Define Metrics for 20 an Enterprise Architecture Program

Niina Hämäläinen and Tommi Kärkkäinen

Integrating Enterprise Architecture and 27 IT Portfolio Management Processes

George Makiya

Case Study

Enterprise Architecture and IT Governance Considerations 41 for Mergers & Acquisitions in Integrating Sarbanes-Oxley

Graeme Downes

(2)

© Journal of Enterprise Architecture – February 2008 2

Scott Bernard, Editor

This quarter’s issue of JEA marks the beginning of the fourth volume of our publication. This achievement, coupled with the steady support of our global readership, are indications that the field of enterprise architecture continues to mature and that there is a need for an approach/product-neutral publication to serve those who develop and assess EA practices and those who deliver EA services to organizations in the public and private sectors around the world. We have another great issue, beginning with a special feature from John Zachman, one of our Associate Editors and the acclaimed “Father of EA”, and very interesting articles from authors in Singapore, Finland, Canada, and the U.S.

I attended a wonderful EA conference in Copenhagen, Denmark in late October that was organized and led by a|EA President John Gotze. There were a number of noted thought leaders and practitioners at the conference from Denmark, Sweeden, Canada, the UK, and the U.S. The November issue of JEA was printed early and brought to the conference because it was a special edition that featured articles from the 2007 “Trends in EA Research” workshop, which all came from European academics and practitioners. The location of the conference, attendees, and recent writings in JEA provided a unique opportunity to discuss the current state of EA in Europe, which is growing dramatically – a reflection of the continuing need for a scalable and integrated business and technology planning approach that supports organizational transformation, helps to manage change and improve performance, and helps to reduce risk when implementing new technologies within and between business units.

The Copenhagen EA Conference also provided an opportunity for the a|EA International Executive Committee to meet (John Gotze of Denmark, Gary Doucet of Canada, Kristian Hjort Madsen of Denmark, and Scott Bernard of the U.S.). We discussed the health of the organization (which is good), and the relationship of a|EA and JEA, which is also good – though significant increases in

JEA printing and mailing costs were noted (I discuss this further below). The Executive Committee also voted to invite Mike Lowe of New Zealand and Richard (Dick) Burk of the U.S. as new general members of the International Executive Committee, and I am happy to report that both accepted. Mike Lowe is a noted senior architect and co-founder of the New Zealand a|EA Chapter (who is featured in this issues’ “Architect in the Spotlight”). Dick Burk recently retired from federal service, where for the last three years he served as the US Government’s leading enterprise architect while at OMB. Dick is now in private practice, advising organizations in a number of countries. Welcome Mike and Dick!

As mentioned, the cost of printing and mailing JEA has risen dramatically during the past year, especially international mailing rates.

Additionally, new international mailing procedures from the US Postal Service require individual customs forms to be filled out when sending documents above letter-type weights, which is quite problematic when hundreds of international subscriber’s copies now need this to be done. It is not uncommon for the price to mail one copy of JEA internationally to exceed

$12.00 USD, double what it cost in 2006.

Therefore, to cover the cost increases and reduce expenses JEA is going to begin offering the journal in both electronic and hardcopy, beginning with this February 2008 issue. There is a slight increase in the subscription price for all members, and all non- US international deliveries of the journal will be electronic, with hardcopy available at an additional rate. Finally, the first year student rate will no longer be offered. These changes will be put into effect over the next few months and the new subscription rates are as follows:

U.S. Domestic Electronic Copies $50/year U.S. Domestic Hardcopy $80/year International Electronic Copies $50/year International Hardcopy $120/year You’ll notice these rate changes on the JEA website (www.aeajournal.org) as well as several new homepage content updates.

Editor’s Corner

(3)

International Executive Committee

President: John Gotze

[email protected]

Vice President: Gary Doucet

[email protected]

Secretary: Kristian Hjort-Madsen

[email protected] Treasurer: Scott Bernard

[email protected]

General Member: Richard Burk

[email protected]

General Member: Mike Lowe

[email protected]

National Chapters

Australia Chapter

Levine Naidoo

[email protected]

Canada Chapter

Mike Giovinazzo [email protected]

Chile Chapter

Alfredo Piquer:

[email protected]

Colombia Chapter

Francisco Ballesteros

[email protected]

Denmark Chapter

John Gotze

[email protected]

India Chapter

Sunil Dutt Jha [email protected]

Ireland Chapter

Joe McGouran

[email protected]

Korea Chapter

John Kang

[email protected]

New Zealand Chapter

Mike Lowe

[email protected]

South Africa Chapter

Graham McLeod [email protected]

Taiwan Chapter

Cathy Sung

[email protected]

United Kingdom Chapter

John Good

[email protected]

United States - Local Chapters

Atlanta Chapter

Andrew LeBlanc

[email protected]

Dallas / Fort Worth Chapter

William Krauter

[email protected]

Delaware Valley Chapter

Michael Robison

[email protected]

California Chapter

Kenneth Griesi

[email protected]

Midwest Chapter

Chuck Ohms

[email protected]

New York Chapter

Brian Clark [email protected]

San Antonio Chapter

Orvis Meador

[email protected]

San Diego Chapter

Karl Garrison

[email protected]

Seattle Chapter

Marci Hadnot

[email protected]

Tampa Chapter

Liesel Muth [email protected]

Washington DC Metro Chapter

John Wu

[email protected]

a|EA Points of Contact

(4)

© Journal of Enterprise Architecture – February 2008 4

Mike Lowe

This issue's featured architect is Mike Lowe from New Zealand, who was recently elected by the a|EA International Executive Committee to serve a two year term as a general member. Mike started his EA work in the UK in the mid eighties. With over 27 years experience, 19 of them in the New Zealand, Mike considers himself a seasoned professional who is passionate about the value that information and technology can deliver to industry. He has held senior management and consulting roles specializing in Enterprise Architecture, Software Development, Program Management and IT Service Management for major public and private sector companies. These include the British Royal Navy, ICL, ANZ Bank, New Zealand Police, and Arthur Andersen.

Mike is the co-founder and Director of Activate New Zealand Limited – a provider of Enterprise Architecture, Portfolio Management and Change Governance consulting services and technologies. He works closely with progressive EA tool vendors like Agilense and Cogniscape.

In 2006 Mike founded the New Zealand Chapter of the Association of Enterprise Architects – he currently holds the position of Membership Chairperson on the Executive Committee.

JEA: How and why did you become interested in EA?

Lowe: Having been a student of De Marco, Gane and Sarson in the early eighties I was both familiar and supportive of a structured approach to architecture and design. In 1984 I was leading the design team on a challenging business change initiative for ICL in the UK.

The proposed solution was going to impact a significant proportion of the workforce. The conventional ‘boxes and line’ diagrams were proving inadequate when communicating the future business models to the key stakeholders.

By adopting a ‘home grown’ graphical notation that pictorially communicated the proposed business events, functions, roles, and processes we were able to not only communicate effectively but simulate demand and predict the outcomes. The success of this approach

established Enterprise Architecture as an essential discipline in my ongoing approach to business change.

JEA: Mike, what is the current state of EA in New Zealand?

Lowe: The majority of Enterprise Architecture in New Zealand is being driven by Architects that have survived careers in IT. The tendency throughout the nineties and early eighties was to focus on improving the IT infrastructure.

Increasingly the business demand for a service orientated enterprise has motivated architects to look beyond the technical and application architecture and look for ways to model the business. There is evidence to suggest this is working well with good progress being made in the key government and industry sectors.

Enterprise Architecture is becoming more widely accepted as a key contributor to economic and socio-economic growth. An excellent example of this is the federated approach to developing and sharing EA artifacts with the primary goal of streamlining government process. We have an active and well supported a|EA chapter established in New Zealand with over 100 interested parties who engage regularly in interest group discussions and meetings. Our primary focus is to promote the value of EA into the executive leadership of our public and private sectors.

JEA: Are there notable differences in how EA is practiced in New Zealand from other areas of the world?

Lowe: On a positive note, New Zealand has many architects that have benefited from a broad array of industry experience. Our ‘can do’

attitude, and willingness to adapt to new challenges, has resulted in a country of motivated generalists – which tend to make good Enterprise Architects. We also have an abundance of creative and lateral thinkers who can ‘think outside the square’ when addressing business challenges.

Architect’s Spotlight

(5)

However, on a less positive note, New Zealand has been slow to react to both the threat and opportunity posed by globalization. Therefore, the demand for new ideas and new thinking has been less than anticipated, resulting in a lesser demand for Enterprise Architecture as a potential contributor to strategic business change initiatives. The net effect being that Enterprise Architecture is mostly confined to IT related programs, with the majority of architects reporting into the IT group.

JEA: If you could harmonize how EA is practiced throughout the world, what would some of the foundational standards be?

Lowe: I believe to harmonize EA would require two foundational standards. First, and most importantly, EA requires a common language that can be used to communicate reference models to all business stakeholders. I see great potential for reference models like Archimate. By combining service orientation and object orientation Archimate has addressed a key requirement of both the business and IT groups.

By applying a common language, architectures can be shared with partner organizations supporting business change across the extended enterprise – this will prove essential in a global economy.

Secondly, there would be benefit in having a unified approach to capturing, modeling and consuming architecture artifacts. TOGAF’s ADM is fast becoming the defacto standard in New Zealand as the preferred development methodology. However, it has evolved from more a technologist’s viewpoint and may require more of a business focus if it is going to succeed – there is far more to Business Architecture than process diagrams.

JEA: What was your most enjoyable EA project and why was it so?

Lowe: After living in New Zealand for 3 years I returned to the UK for 9 months and worked for a major bank in Scotland. The role I had was that of Chief Architect and Project Director for a large lending project. From the outset I was able to lead the architects and the planning team in a collaborative and iterative cycle as we took the strategic goals and objectives and developed, top-down, the various abstractions of architecture and plans. And with each iteration

we were able to validate our models with the business and technology stakeholders. Being in control of the project ensured there were no

‘short cuts’ taken at this very crucial phase of the project. The results were great. The business took ownership from the outset and remained involved and committed throughout. Given the strategic importance to the bank and the numbers of people involved in the change this was a very rewarding experience.

JEA: What was your least enjoyable EA project and why was it so?

Lowe: Whilst working as the EA on a large business transformation project, that would eventually result in the automation of a warehouse, packing and distribution plant, the role required me to communicate the future business operation to around 70 workers who were all about to be made redundant. On the plus side, every difficult question posed by the workers could be answered through the various models used. If nothing else, it showed the business transformation had been well considered and made good commercial sense.

JEA: What advice would you give to someone who is just starting an EA career?

Lowe: To be an effective Enterprise Architect requires excellence in communication and facilitation. Both are skills that can be taught.

Gone are the days when the Enterprise Architect had to have a wealth of institutional knowledge and experience. The modern EA is a facilitator of effective change - working closely with those in the enterprise that have the business knowledge and technical expertise needed for the organization to succeed in the global economy. Also, an old adage that has helped me focus over the years is that, if someone does not understand what you’re trying to communicate – it’s your problem, not theirs.

JEA: What advice would you give to someone who leads an EA practice?

Lowe: I would advise the following:

• Focus on the business, not the technology.

• Market and sell the value of Enterprise Architecture to the Board and the Executive Leadership team.

(6)

• Work closely with Strategist, Business Analysts and Portfolio Managers.

• Ensure you invest in the continued learning of the architects.

• Equip your team with tools that support an inclusive, collaborative approach to capturing and sharing architecture artifacts.

The old CASE-like tools are far too exclusive and in-flexible for a modern architecture practice.

• Last but not least - too many architects I meet are busy reacting to tactical and

operational issues. Architecture must be forethought not an afterthought.

JEA: Any final thoughts?

Lowe: Enterprise Architecture has come a long way in the last 20 years. However, only now are Chief Executives becoming aware of the real business benefits of EA when considering and implementing change. As such, the demand for architecture will increase significantly as this trend continues. There has never been a better time to be involved in this profession.

(7)

Framework Standards, What’s It All About?

By John Zachman

INTRODUCTION

Two years ago, some of my friends pressed me intensely to be more definitive about the Framework concepts. Even though, I had written “The Book,” they were specifically asking me for definitions of the entities that comprise the meta model of Row 2 of the Enterprise Framework. It has taken me and a team of dedicated folks two years, however we have progressed far beyond the original requirement.

We have produced definitions, not only of the meta entities of Row 2 of the Enterprise Framework, but also we have dictionary definitions of the meta entities of Row 1, Row 2, Row 3, Row 4, Row 5 and Row 6 of the Enterprise Framework plus dictionary definitions for the Product Framework (where I learned about the Framework classification in the first place), for the Profession Framework (that I used to call the I/S Framework, the “meta Framework” relative to the Enterprise Framework) and for the Zachman Classification Framework (the Framework classification for all Frameworks).

This work is particularly significant at this point in time for several reasons.

REASONS FOR FRAMEWORK STANDARDS Clarification

Although I first articulated the concepts of the Framework around 1980, 25 years ago, and although the concepts have never changed, and although I have written a book and 30 or more substantive articles about the Framework, there still is some confusion as to the specific contents of the models prescribed by the Framework classification. This is likely due to several reasons.

First, Enterprise Architecture constitutes a paradigm shift and many people have not yet been inclined to make the mental, cultural and

behavioral adjustment to engineering and manufacturing the Enterprise. Second, in some cases we haven’t chosen words, or there have not even been English words available, that accurately convey all of the Framework concepts. Third, we have not used common, universally agreed-upon (dictionary) definitions for the words used to express the concepts.

Fourth, our understanding of the Framework has been enhanced and refined immeasurably over 25 years.

It is only appropriate to review the choice of words to ensure the concepts are conveyed as accurately and clearly as possible.

Enterprise Orientation as Opposed to Information Systems Orientation

From its inception, the Framework has been a classification of descriptive representations of the Enterprise, that is, all of the descriptive representations embodied in the Framework are descriptive of the ENTERPRISE, not simply descriptive of a limited subset of the Enterprise that is related to Information Systems.

The Enterprise descriptions may or may not have anything to do with information systems technologies depending upon whether such technologies are used as the “Builder’s Constraints” in the Row 4 models or not.

Unfortunately, around 1980 when I first drew the Framework graphic, the only words I had at my disposal for the Framework concepts were words from my information systems vocabulary.

Because of my choice of words and because many of the skills required to do the work of Enterprise Architecture are typically found in the Information Systems community, some people misconstrue the Framework intent as an Information Systems schema rather than its true intent as an ENTERPRISE schema.

In the new Framework Standards we have attempted to select words from an ENTERPRISE, general “business” vocabulary,

Special Feature

(8)

not an information systems or technical vocabulary, to correctly convey the idea that Enterprise Architecture is an ENTERPRISE issue, not simply an information or technology issue.

The end object is to engineer and manufacture the ENTERPRISE, not simply to build and run systems.

Consistency

There are two dimensions to the consistency issue. First, there is the universal consistency in the world at large. As global communication and collaboration expands, there is an increasing requirement for semantic coherence. If people’s words do not mean the same thing, there is neither communication nor collaboration. It is imperative for any communication or collaboration within or among Enterprises to define Enterprise Architecture consistently. The instances of Architecture expression in different Enterprises may be different, however the underlying classification and components of Architecture must be consistent for any interoperability (internal or external) to be effected. The instances of Architecture only have to be common in those specific areas of the Enterprise (“slivers” of Framework Cells) in which inter-operation is to be effected but the definition of Enterprise Architecture has to be common throughout..

A second dimension of consistency is that between the “meta” Frameworks of any given Enterprise. The instances of models of one Framework are determined by the Row 2 models of its meta-Framework (see “The Zachman Framework: A Primer for Enterprise

Engineering and Manufacturing”

www.zachmaninternational,com).

Inconsistencies in the meta-structures within an Enterprise would render Enterprise Architecture unmanageable.

Differentiation

Enterprises are complex. Managing the knowledgebase of the Enterprise that is required for Enterprise operation and change is complex.

The key to managing complexity is classification.

The Zachman Framework is a classification system for descriptive representations that constitute the knowledgebase of Enterprises.

However, each Enterprise potentially has four

knowledgebases of importance to them: a) knowledge about their Product (if a product is produced); b) knowledge about the Enterprise itself; c) knowledge about the Professional (likely

“indirect”, “Staff”) community that is engineering (designing) their Enterprise; and, d) knowledge about the classification of knowledge itself.

Although the classification of knowledge (the Zachman Classification system) is the same, the knowledgebases within the Enterprise are different, but related in a deterministic fashion.

The impact of inconsistencies between knowledgebases within an Enterprise is amplified (probably) exponentially (see the comments on Consistency). The Framework Standards clearly differentiates the three knowledgebases, the Profession Framework, the Enterprise Framework and the Product Framework but maintains complete conceptual consistency with knowledge classification itself, the Zachman Classification Framework.

Certification

This may be the most pressing reason for publishing Framework Standards at the present time.

As the Information Age becomes more experientially real, the issues of complexity and change become more urgently confrontational for Enterprises which intensifies the demand for Architecture. Humanity for seven thousand years has found no mechanism for accommodating complexity and change other than Architecture. Therefore, there presently is an increasing demand for “certified” Enterprise Architects. Just as you would want certified engineers engineering your building, certified chemists designing your pharmaceuticals, certified accountants designing your chart of accounts, certified mechanics maintaining your Mercedes, etc., etc., etc. … so should you probably want certified Enterprise Architects engineering (designing) your Enterprise. In fact, if Enterprises are seen to fail because they cannot accommodate complexity and change and people are forced out of work and pension funds cannot be sustained, there might even be regulatory action requiring certification of Enterprise Architecture in the process of licensing Enterprises to operate in any particular political jurisdiction, or to meet federal regulation or meet management behavior control.

(9)

If there are no published standards (criteria against which certification can be measured), certification is purely cosmetic. The concept of certification could be applied not only to Enterprise Architects or to work produced by Enterprise Architects but also to Enterprise Architecture methods and tools. Furthermore, there is also a requirement to establish a standard, “public access” basis for accommodating unique requirements through an elaboration of the base standards as the body of knowledge continues to explode.

Elaboration

The enormous complexity of Enterprises and the vast experience of those people who tend to focus on Enterprise Architecture mandate a capability to accumulate elaborations of the Framework Standards as practitioners’

experience grows.

There has to be a single, authorized facility to publish certified elaborations as well as to publish certified compliance of methods, tools, skills or models to the Zachman Framework Standards. Hopefully this will protect the integrity of the Framework concepts from some of the misperceptions or even distortions of the Framework that derive from maybe well- intentioned, but misinterpreted or misguided self-proclamations of compliance, or even of misunderstanding of basic Framework concepts.

CONCLUSION

The graphic and the meta-model standards overview for the most widely deployed Framework, the Enterprise Framework, will have

“open Access” through a personal use license.

The graphics for the other three Frameworks with complete meta-model standards for all four Frameworks, along with associated elaborations and certifications, will be made available as they are completed on an “open access,” personal use, subscription basis.

I hope you will find the Zachman Framework Standards of great value to your Enterprise Architecture practice.

AUTHOR BIOGRAPHY

John A. Zachman is the originator of the

“Framework for Enterprise Architecture” which

has received broad acceptance around the world as an integrative framework, or "periodic table" of descriptive representations for Enterprises. Mr. Zachman is not only known for this work on Enterprise Architecture, but is also known for his early contributions to IBM’s Information Strategy methodology (Business Systems Planning) as well as to their Executive team planning techniques (Intensive Planning).

Mr. Zachman retired from IBM in 1990, having served them for 26 years. He presently is Chairman of the Board of Zachman Framework Associates, a worldwide consortium managing conformance to the Zachman Framework principles. He is Chief Executive Officer of the Zachman Institute for Framework Advancement (ZIFA), an organization dedicated to advancing the conceptual and implementation states of the art in Enterprise Architecture. He also operates his own education and consulting business, Zachman International.

Mr. Zachman serves on the Executive Council for Information Management and Technology (ECIMT) of the United States Government Accountability Office (GAO). He is a Fellow for the College of Business Administration of the University of North Texas. He serves on the Advisory Board for the Data Resource Management Program at the University of Washington and on the Advisory Board of the Data Administration Management Association International (DAMA-I) from whom he was awarded the 2002 Lifetime Achievement Award.

He was awarded the 2004 Oakland University, Applied Technology in Business (ATIB), Award for IS Excellence and Innovation.

Mr. Zachman has been focusing on Enterprise Architecture since 1970 and has written extensively on the subject. He is the author of the book, “The Zachman Framework for Enterprise Architecture: A Primer on Enterprise Engineering and Manufacturing.” He has facilitated innumerable executive team planning sessions. He travels nationally and internationally, teaching and consulting, and is a popular conference speaker, known for his motivating messages on Enterprise Architecture issues. He has spoken to many thousands of enterprise managers and information professionals on every continent.

In addition to his professional activities, Mr.

Zachman serves on the Elder Council of the

(10)

Church on the Way (First Foursquare Church of Van Nuys, California), the Board of Directors of Living Way Ministries, a radio and television ministry of the Church on the Way, the President’s Cabinet of the King’s College and Seminary, the Board of Directors of the Los Angeles Citywide Children’s Christian Choir and on the Board of Directors of Native Hope International, a Los Angeles-based ministry to the Native American people.

Prior to joining IBM, Mr. Zachman served as a line officer in the United States Navy and is a retired Commander in the U. S. Naval Reserve.

He chaired a panel on "Planning, Development and Maintenance Tools and Methods Integration" for the U.S. National Institute of Standards and Technology. He holds a degree in Chemistry from Northwestern University, has taught at Tufts University, has served on the Board of Councilors for the School of Library and Information Management at the University of Southern California, as a Special Advisor to the School of Library and Information Management at Emporia State University, and on the Advisory Council to the School of Library and Information Management at Dominican University.

2008 Zachman Seminars & Conference Appearances

For additional information or if you are interested in offering any of these seminars in house, please contact [email protected].

Seminars

Series 1: Zachman Framework Masterclass

Seminar 101: Understanding Enterprise Architecture (Led by John Zachman)

Note: You are usually able to take seminar 101 and 102 in the same week.

Feb 19-20, 2008 London, U.K. Register with IRM Mar 4-5, 2008 Ottawa, ON, Canada Register with Intervista May 27-28, 2008 Toronto, ON, Canada Register with Intervista Oct 7-8, 2008 London, U.K. Register with IRM

Seminar 102: Enterprise Architecture Implementation Strategies (Led by Stan Locke)

Perquisite: You should take seminar 101 before taking this seminar.

Feb 21-22, 2008 London, U.K. Register with IRM Mar 6-7, 2008 Ottawa, ON, Canada Register with Intervista May 29-30, 2008 Toronto, ON, Canada Register with Intervista Oct 9-10, 2008 London, U.K. Register with IRM

Series 2: Methodologies Implementing the Zachman Framework

Seminar 211: Enterprise Architecture Concepts and Methodology for Planning and Initiation

Led by John Zachman and Sam Holcman

Feb 11-13, 2008 Wellington, NZ Register with BTELL Feb 13-15, 2008 Brisbane, Australia Register with BTELL Mar 26-28, 2008 Orlando, FL, U.S. Register with ZIFA May 14-16, 2008 Washington, DC, U.S. Register with ZIFA Jul 16-18, 2008 San Diego, CA, U.S. Register with ZIFA Sep 17-19, 2008 Chicago, IL, U.S. Register with ZIFA Nov 17-19, 2008 Phoenix, AZ, U.S. Register with ZIFA

Conferences

The following are a list of conferences where John Zachman and Stan Locke are presenting material on the Zachman Framework:

DAMA International Symposium March 16-20, 2008 in San Diego, CA, U.S.

Enterprise Architecture Conference Europe 2008 June 9-11, 2008 in London, U.K.

Enterprise Information Management Conference June 18-20, 2008 in Toronto, ON, Canada

(11)

The Organization’s Compass – Enterprise Architecture

By Soh Eng Kiat, Lim Han Chiew, Poon See Hong, and Chang Chai Fung

ABSTRACT

This article seeks to establish Enterprise Architecture (EA) as a discipline to achieve an organization’s operating model and position it beyond its current perceived value as framework for standardization and documentation. This is analogous to using a compass, not just to establish the magnetic north but also to chart the direction to go. It describes our operating models, problem space, and the work that has been done to advance the maturity of EA. This is in the form of a foundation layer in the common integrated operating environment that is enabled by our IT governance process. This incremental approach enables projects to incorporate enterprise requirements and collectively build up capabilities to achieve our desired operating model. In this aspect, EA can enable the Ministry of Defense and the Singapore Armed Forces to achieve their operating models - and in the process become their organizational compass.

KEYWORDS

enterprise architecture, operating model, business processes, common data model, governance, reference architecture, defense

INTRODUCTION

Like most organizations, Enterprise Architecture (EA) had been viewed as an information technology (IT) discipline in the Singapore Ministry of Defense (MINDEF) and the Singapore Armed Forces (SAF), where the first

“evidence” of EA has been in the area of technical architecture. However, we are beginning to view EA as the design of the enterprise, and not about IT structures and systems only. This is critical as we align the

“ONE Enterprise” in MINDEF and the SAF.

In this article we show the linkage between EA and the business operating model and contextualize it to the MINDEF and the SAF.

This sets the direction in which the architecture can be designed and defines the foundation required. This foundation aligns subsequent projects and is an incremental approach in which projects funnel through the governance process and contribute to the enterprise needs.

This in turn helps us achieve the operating model desired in MINDEF and the SAF.

BUSINESS OPERATING MODELS

In “Enterprise Architecture as Strategy” (Weill, Ross & Robertson, 2006), the authors concluded from an extensive research of 150 companies that for Enterprise Architecture to be an effective strategy, an organization must first be clear about two key concepts: business process integration and business process standardization. The degree of process standardization and integration that an organization desires defines its operating model.

Deciding on an operating model means making a commitment to how the company will operate.

The purpose of EA is to design the blueprint comprising business processes, data, IT infrastructure and systems to realize the operating model.

Process Standardization means defining exactly how the processes are to be executed regardless of the functional constraints. Process Integration means having different processes linked through a common set of data. Using the business operating model, companies make two important choices in the design of their operations:

(1) The amount of standardization in their processes across units

Article

(12)

(2) The amount of integration in their business processes across units.

An operating model defines the necessary level of business process integration and standardization for delivering goods and services to customers. We adopted Weill, Ross and Robertson’s definitions and identified two models deemed most relevant to our Corporate Information Technology (CIT) and Command and Control (C2) communities – the Unification Model and the Coordination Model.

EXECUTION APPROACH

There are four common elements in approaching enterprise architecture (Weill, Ross

& Robertson, 2006):

• Core Business Processes. The enterprise processes in this small set are the capabilities that a company needs to execute the operating model.

• Shared data driving core processes. This data is shared across the processes instituting the value chain.

• Key linking and automation technologies.

These are technologies used to establish the integration of applications and standardize access to systems.

• Key customers / segments. These are major groups served by the organizations.

• Depending on the operating model, the sequence of the approach varies as we will observe in the Unification and Coordination Models in subsequent paragraphs.

BUSINESS OPERATING MODEL AND EXECUTION APPROACH Unification Model

The Unification Model requires processes to be highly standardized and integrated. It maximizes the efficiency of services by presenting integrated data and driving variability out of processes. As such, the approach is to identify key segments and processes to be standardized and integrated, and also the shared data required to integrate the processes. The focus on technology is to provide visibility of processes and enable the change agents to streamline common processes.

Coordination Model

The Coordination Model requires processes to be highly integrated, but does not demand a high level of standardization. Processes typically share customers, products, suppliers and partners but have unique operations that demand unique capabilities. As such, the approach is to identify the shared segments across the business units, the data to be shared, and address the integration of data. The focus is to derive common data language to enhance coordination across the business units.

MINDEF AND THE SAF OPERATING MODELS

The MINDEF and the SAF Operating Models are primarily demonstrated in the CIT systems and Command and Control Systems respectively.

Determining the operating model would enable us to identify initiatives to enhance the operating model. We recognize that more discussion on the exact operating model has to be established, but it is also critical to solicit a general sensing to kick-start architecture development.

The Unification Model is similar to the majority of MINDEF’s needs for standardization and integration of the CIT systems to drive efficiency.

MINDEF’s manpower, logistic and financial operations are managed centrally and serve the three SAF Services – the Navy, the Air Force and the Army. This model requires processes across the services to be harmonized as they are designed to serve the different services in an optimal manner.

This is evident in an enterprise-level project implemented through a single platform with the centralization of databases which harmonized the logistic processes across the services.

Through the use of common notation standards to describe processes, roles and the linkage to systems (e.g., the ICAM DEFinition Language (IDEF0) is the notation used to describe the

“what” of the processes), the communication approach to users focuses on adapting their existing processes to those found in best practices. Questions asked included “Do we need this role to authorize this? Can others use the same processes?” As a result, the role becomes more clearly defined and processes are streamlined. As the same processes are being used to serve different “customers”, the total cost of ownership is reduced and

(13)

supporting mechanisms such as training become more effective. Any interface point across the functions supporting the processes can be resolved more quickly as there is a common way to view the processes. Currently, a similar approach is being taken for other enterprise projects such as the e-HR. As such, the execution approach for the majority of CIT systems is steering towards unification.

The SAF operational community, however, operates in a very different environment; one that is dynamically changing and fraught with uncertainty. In such an unpredictable environment, processes are constantly adjusted according to the situation. Operational processes therefore differ across the Services and according to the type of weapons used and their operating environment. However, these processes need to be integrated to achieve the overall objective and effect of the military operations.

At the strategic level, where military planning, monitoring and strategic decisions are made, there are more similarities in the processes across the Services. With the ongoing SAF transformation into a unified force, it is likely that the current processes will be transformed to support closer integration among the Services.

This will lead to greater degrees of standardization for these higher-level processes.

We also recognized that across different levels in the organization, given the diverse capabilities

and processes of MINDEF and the SAF, a combination of the Unification and Coordination Model exists. For example, even in the strategic planning of the SAF, a Unification Model could be adopted to maximize efficiency. As such, the Defense Science Technology Agency (DSTA) Enterprise Architecture Office (EA office), being the architecture custodian for both MINDEF and the SAF, has placed emphasis on the components required to lay the foundation for EA. This foundation would be critical to the Operations-Administration Integration for the

“ONE” MINDEF-SAF enterprise.

MINDEF AND THE SAF EXECUTION APPROACH

Next, we attempt to articulate the execution approach through an architecture core diagram.

This would be used to guide the common integration operating environment and governance process. The purpose of MINDEF operations is to provide a coherent front to the needs of the SAF. Thus, the adoption of a Unification Model has led to process standardization in key business domains like human resources and logistics, as well as the consolidation of data and IT services in strategic server farms. This implementation is dominated by major enterprise systems with a centralized data store and served by a well-organized and standardized IT infrastructure. Figure 1 below shows the typical architecture used in the Unification Model.

Figure 1. The Unification Model’s Architecture

Procurement Logistics Finance Manpower

Standardised Processes

Army

Joint

Navy

Air Force

CustomersShared Data

Personal Equipment

…. ….

Budgets

.... ....

“Standardised” Processes

Shared Data

Procurement Logistics Finance Manpower

Standardised Processes

Army

Joint

Navy

Air Force

CustomersShared Data

Personal Equipment

…. ….

Budgets

.... ....

“Standardised” Processes

Shared Data

(14)

The Unification Model shown in Figure 1 on the previous page is contextualized for the CIT environment where the common processes such as manpower and logistics are standardized for the different services. The processes are enabled by a common Enterprise Resource Planning (ERP) platform, which provide shared data on personal and equipment and other data required by the processes.

For the SAF, the operating environment and the people involved are much more diverse.

Furthermore, threats and uncertainty makes coordination and integration a major challenge.

As explained earlier, the operating model for the SAF is likely to be different for the strategic and the tactical levels. For this reason, process integration needs to be simple and efficient. At the tactical level, a simple reporting mechanism is used to push timely information between different levels of command. The information exchange infrastructure and the shared data critical at this level are shown in Figure 2 below.

Figure 2. The Coordination Model’s Architecture The Coordination Model shown in Figure 2

above is contextualized for the IKC2 environment where there are unique processes for different customers. But the unique processes are enabled by the shared common data.

The operating model at the SAF strategic level is likely to straddle between the Unification and

Coordination Models. This is consistent with the architecture put forth by Alan R. Simon (2005).

He revealed that the US military and homeland security departments adopted a hybrid architecture that included a foundational architecture similar to the common integrated operating environment shown in Figure 3 on the next page.

Urban Warfare

Coastal Defence

Air Strike

Unique Processes

Army

Joint

Navy

Air Force

CustomersShared Data

Personal Equipment

….

….

Budgets

.... ....

“Shared” Data Urban

Warfare

Coastal Defence

Air Strike

Unique Processes

Army

Joint

Navy

Air Force

CustomersShared Data

Personal Equipment

….

….

Budgets

.... ....

“Shared” Data

(15)

Figure 3. Hybrid Architecture Model Figure 3 above shows the hybrid architecture. It

is a combination of the Unification Model and the Coordination Model which serve both MINDEF and the SAF respectively. The shared data and standardized processes form the basis of the common integrated operating environment to enable both models.

CREATING COMMON INTEGRATED OPERATING ENVIRONMENT

With a shared understanding of the operating model of MINDEF and the SAF and the execution approaches, the next step is to design and put in place the business processes, as well as the data and the IT infrastructure to realize the operating model. We termed this foundation as the Common Integrated Operating Environment (CIOE). The aim of the CIOE is to provide stability at the implementation level. It must be stable and yet have the agility to grow

and respond to new business opportunities. In addition, it must lead to greater efficiency, lower risks and lower costs.

In our context, the best practices to establish the CIOE would evolve along the following areas (see Figure 4): Clarity of Processes, Common Data Language, Robust and adaptive infrastructure. Depending on the operation model as shown in the hybrid model, the focus could be on processes for the Unification Model or on shared data for the Coordination Model.

Figure 4 on the next page shows the linkage between the operating model and the execution approach. The execution approach is carried out by establishing the common integrated operation environment through the EA governance process. The CIOE would be built up incrementally as enterprise wide projects are being put in place. (Diagram adapted from Weill, Ross & Robertson 2006).

Shared Data Personal Equipment Budgets.... ....

“Shared” Data Urban

Warfare Coastal

Defense

Air Strike Unique Processes

Army

Joint

Navy

Air Force Operations Mission

….

….

Procurement Logistics Finance Manpower

Standardised Processes

…. ….

“Standardised” Processes

Army

Joint

Navy

Air Force Business Mission

Common Integrated Operating Environment

Unification Model Coordination Model

Shared Data Personal Equipment Budgets.... ....

“Shared” Data Urban

Warfare Coastal

Defense

Air Strike Unique Processes

Army

Joint

Navy

Air Force Army

Joint

Navy

Air Force Operations Mission

….

….

Procurement Logistics Finance Manpower

Standardised Processes

…. ….

“Standardised” Processes

Army

Joint

Navy

Air Force Army

Joint

Navy

Air Force Business Mission

Common Integrated Operating Environment

Unification Model Coordination Model

(16)

Figure 4. Linkage of Operating Model and Execution Approach

CLARITY OF PROCESSES

Clarity of processes evolves around establishing a clear linkage of the desired capabilities to the processes and the corresponding enablers (in the form of functions and technology). This is a starting point to articulate the processes to be standardized and integrated and why these decisions are made.

Two ingredients critical to achieving clarity of processes are: leadership and a common architecture framework. The former requires enterprise-wide process owners to be identified and given sufficient authority to own and design areas for improvement. In MINDEF, this authority would be needed to harmonize processes across the Services and is critical for establishing process standardization. These enterprise-wide process owners would require a common architecture framework to facilitate dialogue with other process stakeholders and technical counterparts.

In particular, for the business views pertaining to the CIT operating model, the three tiers of process descriptive architecture are:

• Defense Business Map. This enables investment councils to identify the enterprise capabilities that the project contributes.

• Enabling Processes. Applicable for all projects, this process model identifies the scope of the projects and enables stakeholders to understand the linkages of the project with other existing projects.

IDEF0 is the preferred notation to highlight the touch points and scope of the process.

• Operating Processes. This model describes the how-to of the processes. It provides the design and implementation team with the specific details of the solutions. The notations preferred are Event Process Chart (EPC), Unified Modeling Language (UML), and Business Process Management Notation (BPMN).

Particularly for the CIT operating model, the process owners could leverage the architecture artifacts to discuss the controversial points across the human resource, finance and logistic domains and facilitate the integration. This provides the leverage in subsequent integration with the C2 Systems.

Figure 5 on the next page shows an example of the supply chain management (SCM) capability translated into different levels of details. It shows the SCM in the Business Map being linked to a breakdown of the scope of processes and subsequent detailed processes.

Enterprise Wide Projects

Establishes priorities

EA Governance Learning &

Exploitation

MINDEF/SAF Unification and Coordination Model

Defines integration &

standardization requirements

Refines approach Carried out through

Common Integrated Operating Environment

Clarity of Processes

Common Data Language

Robust and Adaptive Infrastructure Defines Strategic Limits

Integrated Logistics

Integrated Manpower

Integrated Battlelab Projects Projects

…..

Projects

Execution Approach Enterprise Wide Projects

Establishes priorities

EA Governance Learning &

Exploitation

MINDEF/SAF Unification and Coordination Model

Defines integration &

standardization requirements

Refines approach Carried out through

Common Integrated Operating Environment

Clarity of Processes

Common Data Language

Robust and Adaptive Infrastructure Defines Strategic Limits

Integrated Logistics

Integrated Manpower

Integrated Battlelab Projects Projects

…..

Projects

Execution Approach

(17)

Figure 5. Supply Chain Example COMMON DATA LANGUAGE

“Shared data” is a key component in the heart of the Unification and Coordination operating models. In large and complex organizations such as MINDEF and the SAF, there are many interdependencies among the business processes. Each process uses and produces data that may have an impact on other processes. For example, when a soldier is wounded in action, a slew of processes ranging from personnel, medical to the finance department are affected.

It is the timely sharing of the data that effectively integrates the processes and increases the overall efficiency of an organization.

To effectively enable process integration, it is also necessary to establish the relationship among the key data used in different processes.

An enterprise data model is typically developed for this to map out the information model of the business. The model identifies the key data needed to run the business and links them up to create a holistic and integrated view of the business. By making the relationship explicit, the view helps to determine the business rules between the business units. Figure 6 below (adapted from US Army Laboratory) shows an example of how the key data from different military domains are linked up to form an integrated order of battle (ORBAT). Essentially, the operational relationship between units, soldiers and equipment/weapons is a fundamental requirement of military doctrine and operations. An enterprise data model would help to establish and reveal such links from the business perspective. . Effectively, an enterprise data model is the common business language as well as the foundation for process integration, without being dependent on standardized processes. At the implementation level, the enterprise data model serves as the blueprint for building data hubs.

Figure 6. Example of Bringing Disparate Data into a Unified View Defense Business Map

SCM

Make Source

Deliver

Return

Schedule Product Deliveries

Receive Product

Verify Product

Transfer Product

Authorise Supplier Payment Defense Business Map

SCM

Make Source

Deliver

Return Make

Source

Deliver

Return

Schedule Product Deliveries

Receive Product

Verify Product

Transfer Product

Authorise Supplier Payment

(18)

© Journal of Enterprise Architecture – February 2008 18 ROBUST AND ADAPTIVE INFRASTRUCTURE

A robust and adaptive infrastructure is one that is able to provide stability amid the rapid changes in technology and business processes.

Such change-resistant architecture must be built around sound principles such as the following:

• Adopting well-established open and platform-independent standards.

• Adopting a layered and modular architecture so that modules can be replaced without affecting the other elements in the architecture.

• Building integration and reusable services into the infrastructure to facilitate enterprise- wide integration.

A possible architecture is the Service Oriented Architecture (SOA). SOA is an architecture style that promotes stability because it encourages the development of business-oriented services.

These are services that are derived from the business operations rather than from a technical application perspective. When properly built, such services are designed to be application- independent. This makes them more enduring and reusable by any applications.

REALIZING THE OPERATING MODELS From Figure 4, we saw that to deliver value for EA, governance has to be set up to promulgate the CIOE. There are two options. One is to establish an extensive architecture documentation effort. The other method, which we have adopted, is to link the EA to the IT governance process. The latter is preferred as it links the architecture to the actual solutions and keeps the architecture current. As was shown in Figure 4, the enterprise-wide projects would leverage the CIOE and contribute to the CIOE as the projects are funneled through the governance process. As such, we tap on the existing Lifecycle Management process, but introduce gates to address architecture issues.

There are two perspectives to the gates that DSTA managed. One is to ensure that architecture issues are addressed by different stakeholders in DSTA and is facilitated by an established set of IT and business principles.

This will steer projects such that they are built not just to fulfill immediate project needs, but to ensure that there is contribution to the broader enterprise needs. The other is to establish reference architecture so that as our EA knowledge base increases, we are able to collectively reuse solutions and to ensure interoperability. Such reference architecture would be established through the EA3 repository (Bernard, 2005) to different levels of information for different stakeholders.

CONCLUSION

As Peter Weill (2006) pointed out, “Companies should use their enterprise architecture as compass, directing the company towards its intended operating model”. We embarked on EA based on the assumptions that MINDEF is skewed towards the Unification Model and the SAF is skewed towards Coordination Model.

The EA governance and the CIOE had also been built to support the assumed operating model. In the CIT environment, the EA drive was illustrated by an effort to ensure services provided by MINDEF are efficiently executed through clear definition of processes. In the SAF environment, there are also projects to embark on the common data model. These initiatives converge in the hybrid architecture as was shown in Figure 3.

Through the EA governance process, we have embedded requirements for projects to adhere to the broader enterprise goals as they were funneled through the architecture gateways.

While this may result in incremental cost to individual projects, the overall benefit to MINDEF and SAF as an enterprise would be immense. The CIOE would grow as more projects are implemented. This would serve as reference architecture for an adaptive MINDEF and the SAF.

But first, the conversation on the “to-be”

operating model for MINDEF and SAF has to begin. The rest of the alignment processes through EA would then fall in place – the areas of focus for the CIOE and the EA governance. In this respect, enterprise architecture becomes the organizational compass – contributing to how MINDEF and the SAF operate.

(19)

© Journal of Enterprise Architecture – February 2008 19 AUTHOR BIOGRAPHIES

Soh Eng Kiat is Program Manager (Corp IT Enterprise Architecture). He is responsible for the program delivery of the Corporate IT architecture for the MINDEF Information Systems Division. He holds a Bachelor of Science (Information Science) from the University of Tokyo and a Master of Science (Management of Technology) from the Massachusetts Institute of Technology Sloan School of Business. He is also a Certified Enterprise Architect by The Open Group Architecture Framework. He can be reached via email at [email protected].

Lim Han Chiew is Program Manager (DSTA Masterplanning and Systems Architecting). He is responsible for the development of the Information Architecture under the SAF and MINDEF Enterprise Architecture initiative, focusing on data harmonization work, the development of information management strategy and tools, and the development of data integration solutions. Han Chiew holds a Bachelor of Engineering (Civil) from Nanyang Technological University and a Postgraduate Diploma in Computing Technology from NUS.

He further obtained a Master of Science in Software Engineering from the University of Southern California. He can be reached via email at [email protected].

Chang Chai Fung is Assistant Director (Masterplanning, Enterprise Architecting and Governance). She leads the Enterprise Architecting initiatives in DSTA, and is responsible for the establishment and support of the technical governance forum in DSTA. She holds a Master of Technology (Software Engineering) from the Institute of Systems Science, National University of Singapore (NUS). She is also a Certified Enterprise Architect by The Open Group Architecture Framework. He can be reached via email at [email protected].

Poon See Hong is Assistant Director (MINDEF Information Systems Division). His work focuses on integrating strategic Corporate IT (CIT) planning across MINDEF and the SAF and establishing governance and policy for CIT information systems. See Hong holds a Bachelor in Engineering (Mechanical) (Honors) from the Singapore University, and a Master of Science in Military Vehicle Technology from the Royal Military College of Science, UK, under the MINDEF Training Award. He also achieved the distinguished graduate status for the Advanced Management Program and the Chief Information Officer Certificate Program from the Information Resources Management College, National Defense University, USA. He can be reached via email at [email protected].

REFERENCES

Bernard, S. (2005). An Introduction to Enterprise Architecture. AuthorHouse, Bloomington, IL.

Cook, M. (2003). Building Enterprise Information Architecture. Hewlett Packard Professional Books.

Daconta, M. (2003). Designing the Smart-Data Enterprise. Retrieved from http://web-

services.gov/Designing%20the%20Smart- Data%20Enterprise.doc.

Mayo, D. & Tiemann, M. (2005). EA: It’s Not Just for IT Anymore. Journal of Enterprise Architecture, 1(1).

Simon, A. (2005). Real-time, Mission-Critical Business Intelligence: Lessons from the Military and Intelligence Community. CIO Wisdom II.

Prentice Hall.

Weill, P., Ross, J. and Robertson, D. (2006).

Enterprise Architecture as Strategy. Harvard Business School Press.

(20)

© Journal of Enterprise Architecture – February 2008 20

A GOAL-ORIENTED WAY TO DEFINE METRICS FOR AN ENTERPRISE ARCHITECTURE PROGRAM

By Niina Hämäläinen a

nd Tommi Kärkkäinen

ABSTRACT

Metrics are becoming more and more important in the development of enterprise architecture (EA) programs. Therefore, guidelines and support to define metrics for EA programs are needed. A goal-oriented approach for defining metrics for EA program and the measurement aspects for EA program are presented in this article. This approach was developed and tested during the development of proposals of EA program metrics for two companies.

KEYWORDS

enterprise architecture program, metric, measurement, GQM, measurement program, iterative

INTRODUCTION

Measurement and metrics are more and more concerns of EA groups in the development of EA programs. Metrics are seen to be crucial to both managing the development of Enterprise Architecture and to justifying its existence. Value and significance of measurement and metrics for enterprise architecture work is commonly recognized: “Being able to measure, in the meaning of having skills and capability to measure, is essential at all stages of the EA adaptation.” (Christiansen and Gotze, 2007) In addition, consultation companies have stated, for example, “We will begin to see metrics become an integral part of EA and SOA programs” (Cutter Consortium 2007).

However, currently there is very little guidance on metrics that can be captured to help the assessment of EA (Kaisler, et al. 2005). One consequence of this may be that metrics for EA programs are not defined at all. “A recent Forrester survey of more than 50 European enterprise architects revealed that while many enterprise architects were working to achieve specific goals, metrics related to those efforts often did not exist or were not clearly defined”

(Wollmer 2007).

Goal-oriented way has been suggested as an approach to define metrics for EA programs (Cullen 2005; Weiss 2006). However, unclearly defined goals for EA programs are recognized to be an obstacle in the actual definition of metrics (Hoppermann 2007). There seem to be no public guidelines or processes how to carry out the goal-oriented definition of metrics for EA program or these guidelines are very roughly described. Public guidelines or solutions how to handle the problem of unclearly defined goals for EA program in the measurement planning seem not exist.

This article supports the planning of metrics for EA programs by presenting measurement aspects and phases of iterative and goal- oriented metrics development process. In addition, experiences of metrics definition are presented. These were developed and tested during the development of proposals of EA program metrics for two companies.

The remainder of this article is structured as follows. First, measurement program success factors, goal-oriented approach of defining metrics and use of measurement aspects are discussed. Second, the research phases are presented. Third, the measurement aspects and metric planning process is presented. Finally,

Article

References

Related documents

As part of GOL, the CIO Branch developed BTEP (Business Transformation Enablement Program) which provides departments and agencies tools and methods to support strategic

For an EA to be effective and authoritative at all levels and in all dimensions of an enterprise, the EA must integrate the strategy, business, and technology aspects of

As was initially discussed in Part 2, because the highest level Composite Applications are modeled on the business processes they enable and support, the SLA can be

Enterprise Architecture Management, Decision Support Systems, Service-Oriented Architecture, Bayesian Belief Nets, Diagnosis, Failure Impact

Based on a hierarchical, multi-level systems theory approach (Winter & Fischer, 2006) decompose EA into five architectural layers: Business architecture (goal

In closing, the conceptual SOEA architecture depicts the movement of services and data from legacy environments, through a series of extraction, transformation and loading routines,

By using the current EA as a starting point for establishing the context for ERP requirements identification and solution planning, the current business processes of the

A low quality of both strategic and operational architecture management within the process of enterprise transformation is where governance may primarily make use