Towards an Approach to Easy Enterprise Architecture

Although not intended as a formal method the following steps to establishing a first cut enterprise architecture is suggested as a broad approach:

1. Establish Clear Vision and Scope

According to Rico (2006), it is important to know what is to be achieved by the creation of enterprise architect. Enterprise architecture establishment need to be tied to a strategic objective or project. To get things done, and get it done quickly a compelling strategic reason needs to be identified for the enterprise architecture project.

Kotter (1995) suggests as part of his eight step approach that in order to create change, a sense of urgency needs to be established. This is particularly good advice for enterprise architecture development.

Both strategic and operational imperatives like Enterprise Resource Planning (ERP) implementations, business change, mergers and acquisitions, application renewal, transformation road maps, business- IT alignment, infrastructure renewal, legacy transformation and other reasons (http://www.ea-consulting.com/Reports/Enterprise%20Architecture%20Survey%202005%20IFEAD%20v10.pdf) should be considered. Find out what the important strategic issue for the enterprise architecture project is and focus on it.

2. Decide on”Good Enough” Architecture

Design the architecture for flexibility, most-important pieces, and rapid iteration capability (Schulman, 2003). Focus on small, lean and fast (Rico, 2006). Understand minimum requirements for standards, models and principles (Giachetti, 2009).

3. Investigate Reusable Architecture Assets

Understand what architectural assets exists in the enterprise and based on their suitability, include them in the preparation of a first cut enterprise architecture description (Ambler et al, 2005). Understand the impact and consequences of the reuse of existing architecture assets.

4. Define Project Scope

Decide the breadth of coverage and the level of detail to be defined and use it as a starting point for the project (http://www.opengroup.org/architecture/togaf9-doc/arch/). Using ”Good Enough” architecture ensure consideration of the combination of time frame, window and level of effort on the enterprise architecture project(Schulman, 2003).

5. Develop First Cut Architecture Description

Launch and manage the enterprise architecture description project, ensuring that project management principles are applied (Rico, 2006).

References

Ambler S.W., Nalbone J., Vizdos M.J. (2005), The Enterprise Unified Process: Extending the Rational Unified Process, Prentice Hall

Giachetti R.E. (2009), Design for the Entire Business, Industrial Engineer, 41(6):39-43

Kotter J.P. (1995), Leading Change: Why Transformation Efforts Fail, Harvard Business Review, March-April 1995:59-67

Rico, D.F. (2006), A Framework for Measuring ROI Of Enterprise Architecture, Journal of Organizational and End User Computing, 18(2):i-xii

Schulman J. (2003), Defining ‘Good Enough’ Architecture, Available from http://www.bus.umich.edu/KresgePublic/Journals/Gartner/research/115900/115962/115962.pdf, (Accessed 20 September 2009)

TOGAF 9, Available from http://www.opengroup.org/architecture/togaf9-doc/arch/, (accessed 20 September 2009)

Trends in Enterprise Architecture 2005, Available from http://www.ea-consulting.com/Reports/Enterprise%20Architecture%20Survey%202005%20IFEAD%20v10.pdf, (accessed 20 September 2009)

The power of language

Describing enterprise models requires the use of modelling notations and languages. Reusing models, tools and skills already in use in the enterprise has the benefit that no extensive retraining into a new modelling notation may be necessary (see previous posting on reuse). It also has the constraint that previous artifacts may be in different notations if the modelling notation was not previously standardized.

In considering a modelling language, or notation, Jonkers, Lankhorst, Van Buuren, Hoppenbrouwers, Bonsangue and Van der Torre (2004) emphasizes that a coherent description of enterprise architecture allows for agreement, insight and communication among stakeholders. They propose that an integrated language may facilitate the establishment of enterprise architecture.

According to Jonkers et al (2004), different languages are used for enterprise modelling. These include:

• ebXML for XML-based electronic business
• Business process modelling notation (BPMN)
• IDEF, used for function modelling, information and data modelling and process descriptions
• ARIS, focusing on business and organizational modelling
• Testbed, focusing on business modelling
• Unified Modelling Language (UML) ( http://www.uml.org/), which traditionally was used for IT modelling, but which is expanding into business modelling
• Archimate (http://www.archimate.org/), a modelling language focusing on the modelling of enterprise architecture to be used as a companion to TOGAF

The argument is that different domains in the enterprise architecture are typically described through different notations (Jonkers et al, 2004). They propose the development of an integrated language to describe all domains should include descriptions of the level of complexity/abstraction at which should be modelled, the domain specific concepts, the enterprise architecture domains to be included and a description of the relationships, or traceability between domains. A single language will facilitate understanding across the enterprise architecture description.

References:

Archimate, Available from http://www.archimate.org/, (accessed 21 September 2009)

Jonkers H., Lankhorst M., Van Buuren R., Hoppenbrouwers S., Bonsangue M., Van der Torre L. (2004), Concepts for Modelling Enterprise Architectures, International Journal of Cooperative Information Systems, 13(3):257-287

UML, Available from http://www.uml.org/, (accessed 21 September 2009)

The 2nd hand enterprise architecture

Naming this post “the 2^nd hand enterprise architecture” is sure to make a few eyebrows rise. The intention is to bring attention to assets that already exist in the organization and may be reused for creating first-cut enterprise architecture. Ambler, Nalbone, and Vizdos (2005) states that existing enterprise architecture assets may be used to speed up, or kick-start, the development of the first-cut enterprise architecture.

Reusable assets may include reusable domain components, collections of related domain/business classes that work together to support a cohesive set of responsibilities, or service domains which bundle a cohesive collection of services together, existing security frameworks, existing vertical frameworks (e.g. financial frameworks), documented approaches and patterns to solve common problems, collections of classes that implement the basic functionality of a common technical, or business domain, and previously created development artifacts – functional specifications, standards documents, domain-specific models, procedures and guidelines, and even other applications such as a commercial off the shelf (COTS) packages (Ambler et al. 2005).

Ambler et al (2005) cautions that the use of pre-existing artifacts may lock the enterprise architecture team into specific frameworks, methodologies, standards and guidelines, but that it will accelerate the development of enterprise architecture. They further advise that research upfront may bring to light many reusable assets, especially if the enterprise has a track record of formal development methodologies and process. The following figure explains categories of re-use. An architecture description using UML forms the basis of this approach.

Alternatively, architecture (IT architecture) may be reconstructed from legacy systems. Seacord, Plakosh and Lewis (2003) states that architecture reconstruction allows for the creation of system architecture and views on it. It is a process of reverse engineering that assists in recovering architecture assets.

Research into existing artifacts that possibly may be reused may include investigations into:

• Documented strategy
• Documented business process
• Quality process (ISO, CMMI, etc)
• Governance process (Sabanes-Oxley, Basel II)
• Legacy architecture
• Others

Apart from the possibility that reuse of existing architecture assets may have constraints, it may be a rapid kick-start to establishing a first cut enterprise architecture. It enables a jigsaw puzzle approach that allows for quickly building a picture, understanding what pieces are missing and then completing the picture.

References:

Ambler S.W., Nalbone J., Vizdos M.J. (2005), The Enterprise Unified Process: Extending the Rational Unified Process, Prentice Hall

Seacord R.C., Plakosh D., Lewis G.A. (Author), Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices, Addison-Wesley Professional

Enterprise Architecture and the 80/20 rule

Gammelgard, Sim0nsson and Lindstrom (2007), argues that enterprise architecture’s scope is wide and the important enterprise architecture frameworks impose extensively detailed models. They argue that too many enterprise architecture initiatives fail because of overly ambitious models. They further state that it is not possible to create enterprise architectures with models in which every detail is recorded. This raises the issue of the reasonable amount of models that has to be created for enterprise architecture descriptions.

According to Koch (2002), the 80/20 rule was discovered in 1897 by Vilfredo Pareto when he noticed regular patterns in the distributions of wealth, irrespective of country or time period. In the distribution, it was always skewed radically to a small minority of top earners with the majority of the wealth (Koch, 2002). Pareto believed that the discovery would have tremendous potential in other fields, a belief that was proven accurate by Joseph Moses Juran in the 1950’s, who proposed that a great many quality faults could be eliminated quickly by focusing on a few vital causes (Koch, 2002). In the 1960’s this principle became known as the 80/20 rule (Koch, 2002).

The effect of the 80/20 rule is that 80 percent of results will flow from 20 percent of causes, and that 80 percent of reward comes from 20 percent of effort (Koch, 2002).

This rule has massive importance for enterprise architecture projects where time and effort is of the utmost importance. In order to rapidly create enterprise architecture descriptions, that 20 percent of architecture that is going to deliver 80 percent of benefit needs to be the focus. Buchanan and Soley (2002), argues that enormous value can be obtained by following this principle in the analysis of business processes and state that the same effect would follow for enterprise architecture development.

Schulman (2003) argues that ‘good enough’ architecture should rely on the principles of:

• Flexibility – separate different architecture domains away from each other in such a way that changes can be isolated and understood in terms of its effect on other architecture domains.
• Most-important pieces – Use the 80/20 rule and build only the minimum of enterprise architecture that will deliver the maximum benefit. Over time the enterprise architecture can be expanded.
• Rapid iteration capability – The 80/20 rule implies enterprise architecture that will change over time as it is added to and amended. Within the boundaries of the architecture principles it should be easy to revise and add onto the enterprise architecture.

According to Schulman (2003):

“‘Good enough’ architecture represents a more-pragmatic view as an approach to an overall architecture concept. The focus is on agility and changeability, with a rapid response to business and technology architecture. By considering the combination of time frame, window and level of effort, a good enough architecture can be created.”

References:

Buchanan R.D., Soley R.M (2002), Aligning Enterprise Architecture and IT investments with Corporate Goals, Available from http://www.bptrends.com/publicationfiles/META%20OMG%20WP%201-15-03.pdf, (Accessed 20 September 2009)

Gammelgård M., Simonsson M., Lindström Å. (2007), An IT management assessment framework: evaluating enterprise architecture scenarios, Information Systems and e-Business Management, 5(4):415-435

Koch R. (2002), The 80/20 Revolution, Nicholas Brealey Publishing: London

Schulman J. (2003), Defining ‘Good Enough’ Architecture, Available from http://www.bus.umich.edu/KresgePublic/Journals/Gartner/research/115900/115962/115962.pdf, (Accessed 20 September 2009)

Components of Enterprise Architecture

When an enterprise architecture project is launched, according to some strategic imperative, the first consideration in architecting the enterprise is the framework that will be used as a basis for enterprise architecture. Giachetti (2009) distinguishes between the concepts of architectural frameworks, reference architectures and enterprise architectures as follows:

• · An architectural framework describes how enterprise architecture should be developed and what the contents would be
• · Reference architectures are generic architectures that may be used as a basis for establishing enterprise architecture
• · Enterprise architecture is a specific tailored, or developed, architecture that describes a specific enterprise

Many enterprise architecture frameworks exists (as explained in previous posts) and most frameworks will contain varied descriptions focusing on aspects like strategy, architecture, business architecture, information architecture, information systems architecture (including application architecture and data architecture) and technology architecture (http://www.opengroup.org/architecture/togaf9-doc/arch/; Cardwell, 2008, Coetzee, 2004). Depending on the architecture framework selected, different architecture layers should be considered in the process of establishing the enterprise architecture.

According to Giachetti (2009), the end goal of enterprise architecture is to develop enterprise architecture components, or artefacts useful to the enterprise. He elaborates that the enterprise architecture will contain the following:

• · Models – these would be models that describe the enterprise on various levels, from organizational structure, to information, to process descriptions.
• · Architectural principles – principles serving as the foundation for establishing the architecture. TOGAF 9 refers to architectural principles as the general rules and guidelines for architecture implementation, use and management.
• · Standards – standards would describe the skills, business, data and technology standards

Giachetti (2009) states that enterprise architecture should show how all systems (business and technology) work together to deliver enterprise value. Ultimately, enterprise architecture should improve the business.

References:

Cardwell, G. (2008), The Influence of Enterprise Architecture and Process Hierarchies on Company Success, Total Quality Management, 19(1-2):47-55

Coetzee C.F. (2004), Business Analysis Concepts, Lecture

Giachetti R.E. (2009), Design for the Entire Business, Industrial Engineer, 41(6):39-43

TOGAF 9, Available from http://www.opengroup.org/architecture/togaf9-doc/arch/, (accessed 20 September 2009)

Why do you want to implement Enterprise Architecture?

With the proliferation of enterprise architecture frameworks and the number of publications indicating that enterprises will not survive unless a good enterprise foundation for enterprise architecture is established, it becomes easy to drown in all of the the information and opinions regarding enterprise architecture and then in a moment of panic start an overambitious project that ultimately may not bear any resemblance to the strategic direction, or needs, of the enterprise.

So before jumping in – consider why do you want to implement, or create, an enterprise architecture.

By now the benefits of enterprise architecture are clear (see previous posts for elaboration): better, more efficient process, management of risk, standardization, governance, enterprise alignment, rapid (agile change) and many more. All of these reasons are compelling and looks wonderful on a business case, but may not get noticed for the urgency that may underlie the need for an enterprise architecture framework.

The survey “Trends in Enterprise Architecture 2005” (http://www.ea-consulting.com/Reports/Enterprise%20Architecture%20Survey%202005%20IFEAD%20v10.pdf), reveals that respondents considered enterprise architecture as important to their enterprises for the reasons that it supports decision making, assists in managing complexity, delivers insight and an overview of business and Information Technology (IT), it supports system development, it assists in the management of the IT portfolio, it supports business and IT prioritization, it delivers roadmaps for change, it is helpful in mergers and acquisitions, it supports in- and out-sourcing and other reasons.

From this survey it is apparent that respondents had very different opinions regarding the reasons why enterprise architecture is important.

Kotter (1995) suggests as part of his eight step approach that in order to create change, a sense of urgency needs to be established. This is particularly good advice for enterprise architecture development.

To get things done, and get it done quickly a compelling strategic reason needs to be identified for the enterprise architecture project. A further review of a survey “Trends in Enterprise Architecture 2005” (http://www.ea-consulting.com/Reports/Enterprise%20Architecture%20Survey%202005%20IFEAD%20v10.pdf), reveals that enterprise architecture projects are initiated to solve issues like Enterprise Resource Planning (ERP) implementations, business change, mergers and acquisitions, application renewal, transformation road maps, business- IT alignment, infrastructure renewal, legacy transformation and other reasons.

It becomes obvious that enterprise architecture projects are not initiated for one simple reason, but rather as a solution to many, varied and important issues.

Find out what the important strategic issue for your enterprise architecture project is and focus on achieving it!

References:

Kotter J.P. (1995), Leading Change: Why Transformation Efforts Fail, Harvard Business Review, March-April 1995:59-67

Trends in Enterprise Architecture 2005, Available from http://www.ea-consulting.com/Reports/Enterprise%20Architecture%20Survey%202005%20IFEAD%20v10.pdf, (accessed 20 September 2009)

Easy Enterprise Architecture

This post reflects a personal opinion that will be elaborated upon in following posts.

The word “easy” and the words “enterprise architecture” seem incongruous in the same sentence, an oxymoron if you like. Reading about enterprise architecture and talking to enterprise architecture practitioners, and consultants, often leaves us with an unease that such an enterprise architecture implementation is complex beyond expectation and will involve a massive learning curve, together with (as yet unbudgeted for) massive investment, all on top of an extended time span.

This may be true, but before we indulge in worst case scenarios, there is a light at the end of the tunnel (and it’s not a train). Enterprise architecture is not something that needs to be started from a zero basis, but large parts of it may already exist as part of previous projects executed in the organization. Iyer and Gottlieb (2004) argue that enterprise architecture emerges out of the implementation of individual projects.

The implication is then that parts of enterprise architecture that already exist should be investigated and a picture, very much like an incomplete puzzle, should be built.

What should we be looking for?

Enterprise Architectures contains components of strategy, business architecture, information architecture, application architecture, data architecture, and hardware and communications architecture (Cardwell, 2008).

Traditionally, information architecture, application architecture, data architecture and infrastructure architecture is well developed as project and operational artifacts. This may also extend to business architecture from the point of view of business optimization, quality certification and legal and regulatory requirements. Strategy as the primary artifact of the enterprise board and executive management should be documented in various manners.

What about the skills?

Another consideration is the skills required for enterprise architecture development. Existing project artifacts were delivered in the enterprise with existing skills. The focus should be on identifying those skills, evaluating its usefulness and then incorporating it in broad skills set that may be used for the later development of formalised enterprise architecture.

In conclusion, it is the opinion of this author that many artifacts and skills which make up enterprise architecture is present within the enterprise and should be leveraged in a coordination of enterprise architecture, rather than developing enterprise architecture from a zero base.

References

Cardwell G. (2008), The influence of Enterprise Architecture and process hierarchies on company success, Total Quality Management, 19(1-2):47-55

Iyer B., Gottlieb R. (2004), The Four Domain Architecture: An approach to support enterprise architecture design, IBM Systems Journal, 43(3):587-597

The case for enterprise architecture – part 2

In the first part of the case for enterprise architecture, benefits from an information technology (IT) point of view were explored. Focusing only on the benefits to IT would be short-sighted, as enterprise architecture has much to offer business.

Kaplan and Norton (2006), argues that most organizations are uncoordinated, often creating conflict and interference between well-run and efficient business units which somehow creates an inefficient enterprise. They lack a single purpose which unites and directs them as a team rather as individual competitors.

These business units are not aligned and focus on creating value at a business level rather than at an enterprise level. In order to run an efficient and profitable enterprise business units need to be aligned with enterprise strategy to create enterprise value. This needs to be cascaded to the business support functions including information technology. (Kaplan and Norton, 2006).

The ability to extract value from alignment rests squarely on the definition of formalized enterprise architecture.

Business without formal business architecture evolves over time to adapt to changing strategy, markets, regulations and legislation. This leads to a loss of a holistic view to enterprise evolution. The most important benefit of formalized enterprise architecture is the understanding of how different parts, or components, of the enterprise fit together and how it interacts with each other. Understanding business operations and supporting technology facilitates understanding on how business behaviour and technology systems may be reused in standardization and optimization projects. (Giachetti, 2009).

Formalized enterprise architecture considers the long term vision and defines the principles necessary to guide business and projects executed within the enterprise. It takes into account constraints like legal and regulatory changes. The defined enterprise architecture promotes to informed planning and decisions on how best to evolve the enterprise to some future state. (Giachetti, 2009).

Formalized enterprise architecture enables rapid impact assessment of prospective change on all levels of the enterprise and allows rapid response to changing markets, legislation and strategy. Understanding impact mitigates risk of change and enables stakeholders to make the best decisions for change. (Giachetti, 2009).

References

Giachetti R.E. (2009), Design for the Entire Business, Industrial Engineer, 41(6):39-43

Kaplan R.S., Norton D.P. (2006), Alignment, Boston: Harvard Business School Press

Describing Enterprise Architecture

In his seminal paper John Zachman (1987) discusses information architecture and compares it to the process of constructing a building. According to him the architecture serves the purposes of documenting the design, and then convincing the prospective owner that money should be invested in the project to create the design in reality.

Enterprise architecture should address the interests and concerns of the stakeholders. (Zachman, 1987; http://en.wikipedia.org/wiki/IEEE_1471).

Enterprise architecture has its roots in the information and software architectures. The IEEE 1471 (Recommended Practice for Architecture Description of Software-Intensive Systems) specifies that architecture should provide definitions and a meta-model for architecture, should address stakeholder concerns, that it must contain multiple views, content requirements and provide guidance on describing the architecture rationale.

Applying these principles to enterprise architecture, implies that enterprise architectures should provide definitions and meta-models that describe the enterprise, its fundamental organization, its components, the component descriptions and the relationships between them, should address different stakeholder views and interests. It should also describe the principles that govern the design and the evolution of the architecture over time. (Coetzee, 2004).

Coetzee (2004) argues that the components of the enterprise to be contained in the enterprise architecture should be a strategic view, containing strategy descriptions to be accomplished by the enterprise; a business view, which describes organizational functionality, structures and behaviour; a technology view, which describes applications architectures, information architectures and physical technology structure. From the enterprise architecture description, understanding of, and future development of the enterprise should be possible.

Giachetti (2009) specifies that an enterprise architecture description should contain a model to allow for stakeholder understanding and communication, provide a high-level holistic design of the business, express architectural and governing principles, and ensures compliance to regulation and law. The purpose of this is to enable efficiency, reduce costs and improve systems.

The Open Group Architecture Framework (TOGAF) describes enterprise architecture as a blueprint of the enterprise including business, information systems and technology descriptions. Enterprise architecture in this framework offers more efficient information technology operation, reduced risk, improved return on investment and improved procurement.

In conclusion, many different views exist on what should be contained in enterprise architecture descriptions, but agreement exists on the fact that it is a blueprint to establish and guide the design and development of the enterprise. The enterprise architecture description should contain aspects of business, application systems and technology.

References

Coetzee C.F. (2004), Business Analysis Concepts, Lecture

Giachetti R.E. (2009), Design for the Entire Business, Industrial Engineer, 41(6):39-43

IEEE 1471, Available from http://en.wikipedia.org/wiki/IEEE_1471 (Accessed 23 August 2009)

Welcome to TOGAF Version 9, Available from http://www.opengroup.org/architecture/togaf9-doc/arch/ (Accessed 23 August 2009)

Zachman J.A. (1987), A framework for information systems architecture, IBM Systems Journal, 26(3):454-470

The case for enterprise architecture – part 1

Enterprise architecture projects require investment. Not only in monetary, but also in time and skills. The question arises: Why should we consider the implementation of Enterprise Architecture? The answer has to do with the many varied benefits that formalized enterprise architecture brings with it.

Considering just the impact through information technology, according to Ross, Weil and Robertson (2006) the benefits of enterprise architecture are noticeable in the areas of Information Technology (IT) costs, response of IT, management of risk, satisfaction levels of management and the achievement of strategic business objectives.

Standardization and the disciplined execution of IT processes save the enterprise money due to more efficient, visible processes and reduction in time spent on IT support and maintenance. Having clearly defined process aids the effort towards optimization, re-engineering and the monitoring and measurement of operational IT processes.

Better defined and executed IT process also aids in the responsiveness of the IT departments. Systems development is aided by re-use of modular components which reduces time to rollout to the benefit of the systems and user audience.

From a risk perspective, enterprise architecture leads to reduced business risk, increased continuance and a reduction of security breaches. Better systems, uptime and reduced risk contribute to improved management satisfaction with IT and its ability to delivers.

The most compelling reason is the ability of enterprise architecture to facilitate achievement of enterprise objectives. Better systems allows for more customer focus and reaction on customer demand with improved and innovative products. Alignment between business and the systems that support it facilitates rapid change and repositioning in the market in order to meet market demand and opportunity.

References

Ross J.W., Weil P., Robertson D.C. (2006), Enterprise Architecture as Strategy, Boston: Harvard Business School Press