CORA Foundation

Introduction

Organizations who want to introduce new business models and technologies (i.e. create a stable innovation platform) need an IT landscape supporting both flexibility as well as regulatory demands. This is explained in more detail based upon two existing models, the Architectural Maturity by means of the Ross model and Governance by means of the Crown model. Both models provide the foundation for the layering of the CORA. Based on this foundation the connection with existing Vendor Reference Architectures is described.

The "Architecture Maturity Model"

The Architecture Maturity Model was the result of 10 years of research by Dr Jeanne Ross, the Principle Research Scientist at the MIT Center for Information Systems Research. This model shows the four stages organizations move through when building an IT landscape designed to create an innovation platform.

Business Silos architecture
Organizations focus their investments on delivering solutions for local business problems. Interaction between IT systems is complex and expensive due to technology standards not being used. The main force pushing organizations to the next level is the high IT costs of interfacing and not the existence of isolated systems.

Standardized Technology architecture
In this stage organizations shift their IT investments from local applications to shared infrastructure. Instead of looking for technology that best suits a solution, organizations choose the best possible solution within the chosen technology platform.

Optimized Core architecture
In this stage organizations move from a local view of data and applications to an enterprise view. IT investments shift from local applications and shared infrastructure to enterprise systems and shared data. Optimizing core processes and data is a major managerial challenge, because this stage involves taking control over local business unit leaders. 

Business Modularity architecture
Strategic agility can be achieved through customized and reusable modules. According to Ross two approaches can be applied. One is to create reusable modules (i.e. webservices) and allow business units to select customer-oriented processes from a menu of options. A second approach is to grant business unit managers greater discretion in the design of front-end processes, which they can individually build or buy as modules connecting to core data and back-end processes.

This model indicates that taking control over local business unit leaders is necessary to facilitate local deviations in a later stage. This has to do with the fact that individual modules must be build on a standardized core and link to other modules through standardized interfaces in order to provide a stable platform for innovation.

Emering new (Web 2.0) technologies and the Crown model

With the emergence of Web 2.0 technologies new business models are created because of changes in the way information is shared and communicated. These Web 2.0 technologies can be separated into three different categories.

The first category is called ‘Rich Internet Application’. A Rich Internet application (RIA) is a Web application designed to deliver the same features and functions normally associated with desktop applications, such as drag and drop, menus and toolbars. Because the richness is related to functionality, RIA’s are classified as function oriented.

‘Mashups’ are where data and data streams from various sources are fused into a representation that allows for the derivation of new information or added value. With the help of Mashups it is possible to create and share information in a personalized way. The last category is called ‘Socialization of the web’. This where information on the web is tagged by users, not only for individual structuring and ordering, but also for evaluation by other users. This way information is structured and classified in an ‘organic’ way.

Although these new (Web 2.0) technologies can create new flexible business models, they also need to co-exist within standardized (‘compliant’) processes, data and roles.This apparent contradiction is explained in the Crown Model, developed by Andy Mulholland, global CTO of Capgemini.

Personalize (interaction)

As explained earlier, more and more (Web 2.0) technology such as weblogs, wikis and virtual networks (i.e. Facebook, Twitter and LinkedIn) as well as ‘consumerization’ technology (i.e. Smartphone’s and iPods) is available to gain and share knowledge andinformation in a unique personal way. The use of ‘Mashups’, widgets and gadgets is a growing part of this layer as individuals seek to create their own ‘view’ of the immense amount of content that is now available for them to use.

Differentiate (interaction)
Organizations use (Web 2.0) technology such as ‘Rich Internet Applications’ to be able to create innovative solutions with limited delay when business circumstances change. Changes such as trying to gain market share by increasing the variety of offerings to capture more specialised elements of the market. The challenge is that these solutions must connect at some time and in some way with the Enterprise procedures, labelled as ‘Comply’ in the Crown model.

Organize (transaction)
This layer connects the interaction based Differentiation & Personalisation layers to the transaction based Enterprise Applications in the ‘Comply’ layer by using technology standards. The ‘Organise’ layer is where ‘Orchestration’ of internal as well as ‘Choreography’ of external activities (i.e. ‘services’) are managed. The ‘Organize’ layer is the crucial linking and integrating capability layer. To make the role of the ‘Organize’ layer clear it is necessary to move to the lowest layer and describe the role of the ‘Comply’ layer.

Comply (transaction)
Because every organization needs to have strong procedures that manage the integrity of their transactions it is very important to rely on standardized data, roles, authorization and basic processes. The pressure for ‘compliance’ in the form of strong procedures that manage the integrity of the transactions, with resulting data recorded, has grown both through legislation and auditing requirements.

Relationship between Ross and Crown

Both models have a different scope: Ross is a maturity model, Crown is a governance model.

From a maturity perspective Ross’s model emphasizes the managerial challenge needed to facilitate this. For this reason stages should not be skipped due to major organizational changes being encountered at each stage. Ross’s research shows that especially PBS-implementations that tried to skip stages had to be halted or scaled back. From a governance perspective the Crown model emphasizes the influence which individuals have on the behavior of organizations, regarding the way knowledge and information is gained and shared in a personal way.

When comparing the two, both models indicate that implementing an innovation platform to support new business models can only be achieved when the core is stable and technology & governance standards are used. Both models also show that a stable innovation platform is an essential part of the IT architecture landscape. The layering in both models is therefore used as a foundation for the CORA.

Relationship between ‘Crown’, ‘Ross’ and CORA

When using the approach of Ross and Crown to support an architectural guided transformation, the effect on the IT landscape has to be determined and showed to effectively identify and scope IT projects. This becomes clear when the Crown model is mapped to the CORA.

‘Personalize’ and ‘Differentiate’ can be realized by the top three layers ‘Channel access’, ‘Presentation’ and ‘Composition’. They enable flexibility based on a solid integration foundation and business functionality (application and data). ‘Organize’ is possible using the orchestration capabilities of ‘Composition’ and the integration capabilities of ‘Integration’. ‘Comply’ (to rely on standardized data, roles, authorization and basic processes) is mainly focused on ‘Application’, ‘Data’ (and of course ‘Security’).

By combining these three models, an instrument becomes available to effectively guide transformation.

Vendor architectures compared

Various vendors (including Microsoft, SAP, Oracle, IBM/Open Group and Intel) have created their own reference architecture. These architectures are usually aimed at the product stack of the vendor. Therefore they cannot be used solely at Enterprise Level where a variety of technologies and vendors may need to exist. The risk of vendor locking will be inevitable. It must be remembered that the CORA is a vendor agnostic model. Mapping a vendor architecture to the CORA helps to better understand the vendor architecture itself. If no vendor architecture is present it can be designed by using the CORA. It is advisable to use the CORA as a reference architecture and apply vendor architectures to it when vendor products are actually chosen. Various vendor reference architectures (i.e. SAP, Oracle, IBM/Open Group and Microsoft) are mapped onto the CORA.

Original Page: http://www.coramodel.com/cora-model/cora-foundation.html?tmpl=component&print=1&page=

Shared from Read It Later

Sent from my iPad | ross | ross@button.ca | 202-683-7993 | ross.button@cgi.com

LEA: The Enterprise Map

Enterprise Architecture is a holistic approach to emphasize the organic or functional relation between parts and the whole. It is paramount in EA practice for every one to see the enterprise big picture. Silos systems are created due to lack of a visible enterprise big picture. Without a visible enterprise big picture, people can not plan, manage, measure and secure the enterprise. Without a visible enterprise big picture, people can not collaborate and work toward to the same goal. "Knowing in part may make a fine tale, but wisdom comes from seeing the whole"[]

The challenge is how to see the unseen of true enterprise big pictrure. An enterprise is logical and invisible, most people only see their part without knowing the big picture. Further more, people like to believe the part they touched is the whole.

LEA propose the Enterprise Map to see the unseen enterprise big picture.

The Enterprise Map renders the entire Enterprise enviroment for every one to see and touch. It does not describe the business but also illustrate how business take advantage of automation soltuion. The map is constructed under a one page priciple as shown in the following figure:

It is designed from the following aspect based the frequent question to know an enterprise.

What you do?
Who are you?
What you do?
How you do it?
Where are you located?
What is your organization look like?
The organizations around you?
Your automation environment?

The Enteprise Map serve well for community to understand what is Enterprise Architecture about. It illustrate the layer of Business architecture, application architecture, information architecture and technology architecture in one place.

Enterprise Map is a collaborative effort. The large, logical enterprise is invisible by individual because each one of us only touch a part. To see the unseen of enterprise is best illustrated in the story of blind man and the elephant. For the invisible enterprise, Each individual is logically a blind person. EA professional describe EA based on the part they have touched and insisted on their righteousness as described in the story. It is a human nature to think the part they have touched as the whole. The story also point out that Collaboration and reconciliation is only way to see the unseen. Enterprise topology is more so because enterprise is logical, large and invisible. Each one of us only touched a part.

Enterprise map is created and modified based EA experience. It has been very useful for both business and engineering community Security team has found it useful on every case. This is an effort to establish a repeatable and trainable Enterprise Topology method to share the successful EA experience with the others. It lay out of enterprise topology specification and establish the enterprise topology method. Illustrate the topology with example and guide the topology with step by step direction.

Enterprise Map should be the lesson 101 in EA discipline similar to the geographic topology training for all civil engineers. The EA professional should establish the Enterprise Topology first Before jump into architecture design. The capability to see the unseen is a unique EA discipline which distinguish EA professional from general architects. The Enterprise Map, similar to a large jigsaw puzzle, is composed step by step with collaborative effort.

^ TOP

Posted on 20:21:57 by LEA - No comments

Background

alex osterwalder business model canvas

Business Canvas

Model http://en.wikipedia.org/wiki/Business_Model_Canvas and the online tool that support it, such as BMDesigner http://bmdesigner.com.

Business Canvas game

1. Enterprise map by Burton, Herbert O, Pennotti, Michael C.

Enterprise map: A system for implementing strategy and achieving operational excellence in Engineering Management Journal , Sep 2003

"Abstract: This article describes how senior leaders can use the tools and techniques of systems analysis to develop a top-level process architecture that identifies the key processes of a business and specifies the critical interconnections and interrelationships between them. We call this top-level architecture an enterprise map and we believe it represents an important addition to a senior management toolkit, complementing other popular, performance-enhancing tools like process maps (Eckes, 2001) and the balanced scorecard (Kaplan and Norton, 1992)."

There are many graphic representation effort in IT architecture practice, the Enterprise topology leverage on the concept and the effort from the following :

2. Bernard H. Boar's effort

The Enterprise Topology is developed under the influence of Mr. Bernard H. Boar. He is Director of Strategic Solutions for RCG Information Technology in Iselin, New Jersey. He is an internationally recognized expert on IT strategy, and the author of several successful books on the subject, including Practical Steps for Aligning Information Technology with Business Strategies and The Art of Information Technology Strategy, both of which are available from Wiley.

"This book is the answer to hundreds of CIOs who have asked me how IT can be used to disrupt their market and change the rules of competition. If you live in a hypercompetitive world, CIOs will find this book an invaluable resource." —Richard A. D'Aveni, author of Hypercompetition "I wish Bernie Boar had written this book 20 years ago. And I wish every IT manager and architect had read it and placed his hand on it and sworn by it 20 years ago. Then we wouldn't be in the pickle we find ourselves in today!" —John A. Zachman Constructing Blueprints for Enterprise IT Architectures Recently deployed within a unit at AT&T, Enterprise IT Architecture Blueprinting (EAB) lets you blueprint your system designs with a degree of precision long taken for granted by engineers and architects. In fact, it's the first standardized methodology of its kind. In this book, expert Bernard Boar introduces you to the principles behind EAB and all of its features by walking through the entire design process for developing conceptual, functional, logical, and physical blueprints complete with useful icons, diagrams, and page templates.

3. C4ISR products

DoDAF v1.0 listed the following products as the "minimum set of products required to satisfy the definition of an OV, SV and TV." One note: while the DoDAF does not list the OV-1 artifact as a core product, its development is strongly encouraged. The sequence of the artifacts listed below gives a suggested order in which the artifacts could be developed. The actual sequence of view generation and their potential customization is a function of the application domain and the specific needs of the effort.

AV-1 Overview and Summary Information
AV-2 Integrated Dictionary
OV-1 High Level Operational Concept Graphic
OV-5 Operational Activity Model
OV-2 Operational Node Connectivity Description
OV-3 Operational Informational Exchange Matrix
SV-1 System Interface Description
TV-1 Technical Standards Profile

4. Unified Modeling Language

UML 2.0 has 13 types of diagrams, which can be categorized hierarchically as follows:

Structure diagrams emphasize what things must be in the system being modeled:

Activity diagram
State Machine diagram
Use case diagram
Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

Communication diagram
Interaction overview diagram (added in UML 2.x)
Sequence diagram
Timing diagram (added in UML 2.x)

Original Page: http://www.liteea.com/topology.php?catid=568&blogid=7

Shared from Read It Later

Sent from my iPad | ross | ross@button.ca | 202-683-7993 | ross.button@cgi.com

EA products

The IT Architecture & Strategy Framework (ITAASF) is a proprietary framework available to our customers in the following manners:

• ITAASF methodology (planned for 2011-Q2)
• ITAASF course (where the framework is explained including the key persistent EA products)
• ITAASF as a Casewise model/extension (which supports the creation and maintenance of all EA artefacts produced by an enterprise architecture group, it is currently being built and planned for 2011-Q2)

The following image represents the ITAAS Framework with some key persistent EA products and EA offerings. The EA products are artefacts that should be maintained continuously in order to be available when there is an EA demand. We like to see enterprise architecture groups been structured as EA Practices and consequently the EA Practice maintain an EA Services/Products Offerings available to its business customers. 

Original Page: http://www.itarchitectureandstrategy.com/en/products/ea-products

Shared from Read It Later

Sent from my iPad | ross | ross@button.ca | 202-683-7993 | ross.button@cgi.com

EA FAQ

This page doesn't appear to be an article and therefore may not display well in the Article View. You may want to switch to the Full Web Page view.

If you know there should be an article here, help improve the article parser by reporting this page. Thanks!

Original Page: http://www.enterprise-architecture-matters.co.uk/ea-links

Shared from Read It Later

Sent from my iPad | ross | ross@button.ca | 202-683-7993 | ross.button@cgi.com

Distinguish Reference Model and Reference Architecture

Distinguish EA Reference Model, Reference Architecture

Many EA professional are confused with the term of reference model abd reference architecture. The Coherent EA suggest that :

• Reference Model serve as the architecture taxonomy to establish the common architecture communication platform;

• Reference Architecture as the Enterprise Architecture template based on LOB.

Enterprise Architecture is initiated to overcome the challenge of stovepipe system as part of information age evolution. For the purpose of making transition from stovepipe system culture to an interoperable culture, it is essential to establish the common communication platform between architecture professionals so that they can communicate to learn experiences of each other, share information and consolidate resources across their enterprise internally and the industry externally.

EA Reference Models are the fundamental foundation of EA to overcome the challenge of stovepipe culture. With this vision, the US OMB FEAPMO has establishes the reference models as the common communication platform in Performance, Business, Services, Data, and Technology. It defines the architecture categories and taxonomy for the architects to communicate in the same language and learn the right experience. OMB also uses the reference models for Enterprise Architecture assessment.

The concept of Reference Model seems simple and clear based on the need to overcome the stovepipe system.

However, the concept of Reference Model has cause significant confusion in the stovepipe oriented IT community and even the EA professionals because it is something they do have to think about before in the stovepipe culture. .

Distinguish Reference Model from Reference Architecture

Reference Models are frequently confused with Reference Architecture. The Reference Models serves as the common communication platform to enable total participation. It establish the architecture taxonomy . Reference Architectures on the other hand are the architecture template which can be reuse to expedite architecture design. In the stovepipe culture, there is no need to communicate and learn experience of the others. As a matter of fact, most IT professional are quite arrogant and put down the experiences of others. They do not see the need of reference model as the taxonomy to communicate with other architects.

It is critical to use the same reference model to reuse and share the right resources. While Reference model and Reference Architecture serve different purpose, the architects need the reference model to adopt the right architecture template. The risk of learning experience of the others is learning the wrong experiences. A reference model enable the architects to adopt the right template in the right context.

Original Page: http://it.toolbox.com/blogs/lea-blog/distinguish-reference-model-and-reference-architecture-30949

Shared from Read It Later

Sent from my iPad | ross | ross@button.ca | 202-683-7993 | ross.button@cgi.com