Main Index HOME Search Posts SEARCH
POSTS
Log in LOG
IN

Home: Chapters & Groups: EA Management Guide:
Chapter 6. Enterprise Architecture Designs

 



hp
/ Moderator

Mar 23, 2007, 7:22 PM

Post #1 of 17 (51559 views)
Shortcut
Chapter 6. Enterprise Architecture Designs Can't Post

This is the top level for Chapter 6.

Below are some frequently viewed links in this thread to help you navigate contents in this thread.

Chapter 6, Draft 1:
http://www.aeablogs.org/...forum.cgi?post=76#76

EA Alignment Framework:
http://www.aeablogs.org/...forum.cgi?post=85#85

Chapter 6 (Draft 2): Architecture Design Patterns by Management Area
http://www.aeablogs.org/...rum.cgi?post=275#275


(This post was edited by hp on Oct 15, 2009, 6:52 AM)


hp
/ Moderator

Mar 23, 2007, 7:58 PM

Post #2 of 17 (51543 views)
Shortcut
Chapter 6. EA Designs - Draft 1 [In reply to] Can't Post

In Draft 1, this chapter is chapter 5.
Attachments: draft1_1-chpt-5-EA-designs-2006-9-27.doc (1.39 MB)


hp
/ Moderator

Mar 24, 2007, 10:00 AM

Post #3 of 17 (51537 views)
Shortcut
EA Alighment Framework: links EA designs to Enterprise Management [In reply to] Can't Post

Chapter 6, EA Designs, introduces an EA Alignment Framework to organize architectural designs and to implement architectural integrity.

-The key value of the EA Alignment Framework is to link designs with the end result, i.e., using the designs to improve specific managements, throughout the designing process.

-The EA Alignment Framework extracts and implements strengths from multiple frameworks, such as Zachman Framework, GERAM, TOGAF Framework, FEAF, DODAF, NGOSS, and EA Cube, to establish design integrity, to connect designs with their management purposes and outcomes, and to coordinate designs with EA information models.

What it does and what it doesn't do:
- The EA Alignment Framework provides multi-dimensional perspectives, aspects, alignment mechanisms, and decision support capabilities.

The five essential alignment dimensions for total architecture optimization are:
  1. Attribute dimension: Align with its purpose.
  2. Object dimension: Align among components and management areas.
  3. Decomposition dimension: Align along decision-to-implementation hierarchy.
  4. Time dimension: Align along lifecycles and timelines.
  5. Dynamic dimension: Align with the changing environment.




The framework can provide many views from many different perspectives, including but not limited to:
-- Enterprise management perspectives
-- Architectural layers
-- Element-entity Lifecycle phases
-- Element-entity characteristics/attributes
-- Various EA Continua
-- Expandable views

Sample use of the Alignment Framework:
- The generic enterprise management architecture can be used to identify quickly all management functions needed to establish or operate any enterprise; to identify quickly all requirement areas needed for designing, building, operating and retiring any components.

- The Alignment Framework can be used to build metamodels for EA repositories and to build decision-support capablities.

- The Alignment Framework does not include architecting processes. Architecting processes are organized in the Architecting Lifecycle Management Matrix (EAMG Chapter 7).

- The Alignment Framework addresses what to align and how to link elements information for alignment use. It does not cover how to align specific architecture components. How to Align is addressed in the EA Management Methodology Matrix (EAMG Chapter 4).


(This post was edited by hp on Mar 14, 2010, 7:44 AM)
  EA-Alignment-Framework-2009-6-28.ppt (648 KB)


Chris Aitken
Dr

Apr 16, 2007, 2:15 PM

Post #4 of 17 (51487 views)
Shortcut
Re: 6.2. Designs for EA Integrity, Drafted by Chris Aitken [In reply to] Can't Post

There has been some discussion (out this forum) that this draft would be better placed in the chapters that deal with modeling. While I'm happy for it to be moved to the modeling chapter I think that to do so misses the bigger implications of the framework set out in the draft.

There are two issues that I think need addressing first:
1. The role of modeling within the EA development process
2. The distinction (if any) between design and the architecture development process

In my experience the process of modeling is the central modus operandi for developing EA artifacts and plays a central role in the development of an EA. However, the execution of the modeling process frequently lacks the rigor required - using ad hoc conventions, lack of definition of the various levels of abstraction etc. What I'd suggest is that a similar methodology to the six sigma quality management paradigm (ie. an application of the scientific method) be applied to the process of EA artifact development. In this way models become much more than simple visualizations of an entity, they become a powerful, accurate and predictive abstraction of the actual entity and its relationships.

Regards the design vs architecture debate. I am of the opinion that the terms 'architecture' and 'design' primarily reflect a difference in scope or scale rather than a difference process. If I am dealing with an individual IT system I typically refer to 'designing' it. If I am dealing with an enterprise it is typically understood that I am 'architecting' it. In my opinion the processes of architecting and designing are essentially the same - the main dimension along which they differ is scale. The recursive nature of the Zachman Framework (and others) suggests that this is correct. That is, I can use the same framework to describe the 'design' of an entity as I can to describe the 'architecture' of an enterprise.

All this is by way of saying that I feel that the current chapter is the correct location for the draft section - there are some points that may be need to be made more clearly in the next revision that pick up on the enterprise wide implications and application of the framework it describes.

Comments/thoughts?

[Note attachment has been removed as it has since been published else where]


(This post was edited by caitken on Nov 12, 2007, 1:29 AM)


hp
/ Moderator

Apr 17, 2007, 1:26 PM

Post #5 of 17 (51392 views)
Shortcut
Re: 6.2. Designs for EA Integrity, Drafted by Chris Aitken [In reply to] Can't Post

I think your section belongs to the design chapter.

Regarding the definition of "architecture", in terms of a building, architecture is the arrangement that holds the building together. A drawing of the architecture is not the architecture itself, but a representation of the architecture. An architecture can be represented in many ways, such as a diagram, a picture, a wood model, a textual description, a shade, ... None of these representations is actually holding the building together, so they are not the architecture itself. They only express the architecture. A design is a means to represent a contemplated architecture.


Chris Aitken
Dr

Apr 17, 2007, 3:59 PM

Post #6 of 17 (51386 views)
Shortcut
Re: 6.2. Designs for EA Integrity, Drafted by Chris Aitken [In reply to] Can't Post

I agree that a drawing is not the building's architecture, in the same way that it is also not the building - nor is it the design of the building. A drawing is a representation (abstraction) of the building's architecture, the building and its design. I'd contend that an architecture can only be represented using an abstraction.

I think that your definition of architecture as the "arrangement that holds the building together" is in danger of confusing the enterprise (building) with the architecture. I'd suggest that the building/enterprise's cohesiveness is also part of its architecture?

I'd suggest that an architecture is independent of the building/enteprise/object in which it is implemented. The architecture exists before and after the lifespan of the implemented building/enterprise/object. To use a very bad and simplistic analogy an architecture is like the process of evolution - you can't touch it but you can readily see the effects of it :-)

In the framework that I have presented here an architecture is the sum of all the design principles (explicitly or implicitly used) in the design and implementation of an object/enterprise. You can test design principles by using carefully constructed assertions. This is the mechanism, I believe, by which we might objectively undertake the process of architecting.

Comments?


hp
/ Moderator

Apr 18, 2007, 5:26 AM

Post #7 of 17 (51382 views)
Shortcut
Re: 6.2. Designs for EA Integrity, Drafted by Chris Aitken [In reply to] Can't Post

If architecture is the principles, can we have a bad architecture that does not comform to principles? I have seen many, I think.
But again, how to define architecture is up to people. For a book's scope, keeping one definition is only to make sure a term means only one thing in the book so less confusion. Of course, the term shouldn't be a wrong one.
Regardless, please keep the thoughts flow. Your thoughts and points are well thought of. All thoughts are needed.


(This post was edited by haiping on Apr 18, 2007, 5:40 AM)


hp
/ Moderator

Jun 28, 2007, 11:38 AM

Post #8 of 17 (50062 views)
Shortcut
6.2. Designs for Architectural Integrity [In reply to] Can't Post

This is the top level for 6.2. Designs for Architectural Integrity.


hp
/ Moderator

Jun 28, 2007, 11:39 AM

Post #9 of 17 (50061 views)
Shortcut
6.3. Designs for Strategic Management. [In reply to] Can't Post

This is the top level for 6.3. Designs for Strategic Management.


hp
/ Moderator

Jun 28, 2007, 11:40 AM

Post #10 of 17 (50059 views)
Shortcut
6.4. Designs for Business Management [In reply to] Can't Post

This is the top level for 6.4. Designs for Business Management.


hp
/ Moderator

Jun 28, 2007, 11:41 AM

Post #11 of 17 (50057 views)
Shortcut
6.5. Designs for Resource Management [In reply to] Can't Post

This is the top level for 6.5. Designs for Resource Management.


hp
/ Moderator

Jun 28, 2007, 11:41 AM

Post #12 of 17 (50056 views)
Shortcut
6.6. Designs for Risk Management [In reply to] Can't Post

This is the top level for 6.6. Designs for Risk Management.


hp
/ Moderator

Jun 28, 2007, 11:42 AM

Post #13 of 17 (50055 views)
Shortcut
6.7. Designs for Electronic Management [In reply to] Can't Post

This is the top level for 6.7. Designs for Electronic Management.


hp
/ Moderator

Jun 28, 2007, 11:43 AM

Post #14 of 17 (50055 views)
Shortcut
6.8. Designs for Architectural Transition [In reply to] Can't Post

This is the top level for 6.8. Designs for Architectural Transition.


hp
/ Moderator

Jun 28, 2007, 11:46 AM

Post #15 of 17 (50054 views)
Shortcut
Transition Methodology by Comsys [In reply to] Can't Post

The Comsys Transformation & Integration Methodology (TIM) encompasses the collective disciplines and strategy required for:
Integrating data and systems across and beyond the enterprise Integrating legacy systems and new, Internet-driven technologies Migrating systems and business rules to new architectures, languages and web-based environments Managing and ensuring systems quality and stability

http://www.comsysprojects.com/...ion/TMethodology.htm


hp
/ Moderator

Jul 5, 2007, 6:24 PM

Post #16 of 17 (46251 views)
Shortcut
Architecting Line of Business (LOBs) [In reply to] Can't Post

This is the top level for Line of Business (LOB) Architecting.

Before discussing LOB architecting, it is important to identify different type of LOB architecting. The LOB architecting discussion should indicate which type of LOB architecting the thread is talking about.

LOB architecting has different types of purpose:
  • Architecting the LOB as a business process segment within a centralized enterprise.
  • Architecting the LOB as a sub-enterprise within a federated enterprise.
  • Architecting the LOB as a cross-enterprise service among independent enterprises.
  • Architecting the LOB as a vertical supply chain among independent enterprises.

Different types affect the scope, objectives, participants, and approach of LOB architecting.

A high level overview of the different LOB architecting types:
  • Architecting the LOB as a business process segment within a centralized enterprise.
    • This architecting type focuses on aligning special business processes that are related to the specific LOB within an enterprise.
    • The alignment assumes all other management groups are centralized, available as services, and beyond direct control of this LOB.
    • The alignment takes applicable input from external LOB stakeholders and other management groups, optimizes its own LOB-specific business processes, and matches output with demands from external LOB stakeholders and other management groups.
    • The architecting scope boundary is at LOB’s internal process level.

  • Architecting the LOB as a sub-enterprise within a federated enterprise.
    • This architecting type treats the LOB as a whole enterprise by its own, although it has a parent enterprise to report to and some peer sub-enterprises to coordinate with.
    • The alignment includes all management groups under the authority of the LOB sub-enterprise, and assumes the parent enterprise and peer enterprises are beyond direct control of this LOB.
    • The alignment takes input from external LOB stakeholders, parent enterprise, peer sub-enterprises, optimize all management groups in the LOB, (including the specific business processes for this LOB), and matches output with demands from external LOB stakeholders, the parent enterprise, and peer sub-enterprises.
    • The architecting scope boundary is at sub-enterprise level, including processes and other management groups.

  • Architecting the LOB as a cross-enterprise service among independent enterprises.
    • This architecting type focuses on aligning special LOB business processes that are commonly shared by independent enterprises and delivering the shared process as a service.
    • The alignment may take a service-side or a client-side perspective.
    • The service-side alignment extracts common LOB functions from service receivers, optimizes the shared LOB-specific processes, and matches output with demands from LOB service receivers.
    • The client-side alignment identifies serviced functions and remaining internal functions, optimizes internal LOB-specific processes along with serviced processes, and matches output with demands from LOB’s external stakeholders and other enterprise management groups.
    • The architecting scope boundary is at LOB process level, including shared and internal processes.

  • Architecting the LOB as a supply chain along independent enterprises.
    • This architecting type focuses on aligning the sequence of LOB business processes that move a product or service from raw material supplier to final end customer and that are passing through independent enterprises.
    • The alignment treats all participating enterprises as market partners in this LOB.
    • The alignment takes a final customer’s perspective as well as all enterprise owners’ perspectives to optimize all business processes along the whole supply chain, and matches output with demands from external LOB stakeholders and partner’s own management groups.
    • The alignment may be sought externally through explicit and prior coordination among the supply chain participants, using mechanisms such as vertical contracts and service agreements to control the flow of input and output. Or the alignment may be sought internally through vertical market studies and internal process adjustment to respond to market signals.
    • The architecting scope boundary is at supply chain process level, including shared and internal processes.



(This post was edited by haiping on Jul 29, 2007, 6:30 PM)


hp
/ Moderator

Sep 26, 2009, 3:17 PM

Post #17 of 17 (31393 views)
Shortcut
Chapter 6. EA Design Patterns by Management Area [In reply to] Can't Post

(This is a work-in-progress product. All are invited to comment and contribute patterns, common processes, principle, and other EA products.)

This portion of Chapter 6 assembles architecture design patterns by enterprise management area/domain.
Each section follows the template below to present the content:

6.1.1.1 What: what this management domain manages.
6.1.1.2 Why: what purposes and goals this management domain should serve and achieve.
6.1.1.3 Principles: what are the fundamental requirements for this management domain.
6.1.1.4 Processes: what are the major processes in this management domain.
6.1.1.5 Structure patterns:
a. Management structure: the structure patterns for decision making and execution in this domain.
b. Object structure: the structure patterns for things being managed in this domain.
6.1.1.6 EA products and analyses: what types of EA products and analyses can be used to help manage and improve the architecture of this management domain.
6.1.1.7 EA metamodel: samples of major data entities and relationships for an EA repository to document and manage the architecture of this management domain.
6.1.1.8 References: references materials for the architecture of this management domain.


(This post was edited by hp on Feb 8, 2010, 6:30 PM)
Attachments: chapter-6-mgmt-area-patterns-2009-12-31.doc (347 KB)

 
 


Search for (options) Powered by Gossamer Forum v.1.2.3