enterprise architecture governance november 2008 ian koenig

Enterprise Architecture GovernanceNovember 2008

Ian Koenig

Copyright © Ian Koenig

The Opportunity - Governance

• Technology is complex

• It is only getting more complex

• Solving the real big problems takes multiple iterations and multiple years

• While you focus on one problem, other parts of the technology landscape start decaying according to a predictable trajectory

• Managing the whole process requires Governance

2

Copyright © Ian Koenig 3

Technology Governance is a

Process that builds on

Standards and Policies, producing a set of

Metrics so that an

Organization can manage the eventual convergence of the technology with the architecture.

What is Technology Governance?


STA

RT

DESTINATIONYou are

here

Death by Governance

I.T . AnarchyI.T. Control

Headquarters

Don’t overshoot

Don’t overshoot – Death by Governance


Architecture Governance

• Architecture Governance is only one part of proper I.T. governance.

• Best results are achieved when the level of rigor applied matches the appetite of the organization to consume it.

• Architecture Governance should be integrated into the Software Development lifecycle and not act stand-alone.

• The goal of the process is to measure each significant technology implementation against the organizations own defined standards and policies and produce objective metrics so that business decisions (i.e. cost / benefit decisions) can be made.

• The process repeats so that defects and known deviations from standards can be corrected in the fullness of time.

5


Standards and Policies – Derived from Principles

• Standards and Policies are the “Rules” that you govern to

• Focus on the “50” Rules that Matter. Leave the “5000 really good ideas” for another day.

• Start with a set of Principles. Principles read like Mission statements. Standards and Policies are the concrete rules that help you know you comply with the Principle.

6


1. As Simple as Possible and no simpler: Following well-defined patterns and blue-prints; Duplicate as little as possible based on organizational reality

2. Separation of Concerns (Modularity): Divide labor among encapsulated components that are loosely-coupled via well defined interfaces, entities and data models.

3. Standards Compliant: Compliant with corporate (and industry) standards. Requires the Corporation to state its position on Industry standards and technology stacks.

4. Protects Intellectual Property: Protecting the Intellectual Property of the corporation and not infringing the intellectual property of 3rd parties.

5. Maintainable and Extendable: Software and systems are easily maintained and able to be extended into adjacent functional areas with minimal surgery.

6. Secure: Protect and preserve access to proprietary services and confidential information in the company’s systems. Transport information in a secure manner as necessary for the class of information.

7. Scalable: Support load increases via a proportional increase in resources in a cost-effective manner.

8. Manageable: Designed with hooks to monitor, measure and modify operational behavior adopting operational best practices. Know what your systems are doing before your customers do. Resolve issues before they become issues.

9. Reliable: Provide measurable service in terms of responsiveness, availability and dependability during normal operation, in failure scenarios and in the event of a disaster.

10.Global (or not): If Global, designed with capability to be localized for use outside the “English-speaking” world, including language, script, and culture; including: currency, color conventions, holidays, sort-order, et al

The principles of an Enterprise Architecture are like its Mission Statements. For more information refer to: http://pro.iankoenig.com/docs/Principles.pdf.

The more constraints one imposes, the more one frees one's self. And the arbitrariness of the constraint serves only to obtain precision of execution. – Igor Stravinsky

Principles – Starter for “10”


To Govern Technology you must first communicate

• Given Architecture Principles…

• … Extrapolated into the 50 rules that matter…

• … In order to produce the Metrics that are the basis of non-subjective, iterative governance ….

• … You must measure your technology against your defined standards and policies

8

But first you must communicate what the technology does in a precise and complete way.


Architecture Diagramming – The communication

• When it comes to describing technology, a picture really is worth a 1000 words.

• But if the pictures can be made “smarter” and “livelier”, maybe they would be worth 1,000,000 words?

• There are already some pretty good starting places like UML as a language and Microsoft Visio as a tool. This way, you don’t have to reinvent the wheel. “Just build the car”

• The diagramming style guide for Logical architecture using UML as a starting point can be found at: http://pro.iankoenig.com/docs/LogicalArchitecturalDrawingGuidelinesv3.pdf

9


The Perspective View

10

My Enterprise Internal Data

Feed

Symbol Support

Support

System 2

External Display

Application

Internal Display

Application

Syste

m

Su

ppo

rted B

y M

e

My System

W

W

XBRL

F

Binary Format 1

W

W

W

Interface 2 Interface 1

W W

Interface 3

W

Output Model 2 Output

Model 1

External Data Feeds


System View - 1

11

My Enterprise Internal Data

Feed

Sym

bol S

upport

Support

System

2

External Display

Application

Internal Display

Application

W XBRL

Binary Format 1

W

W

W

Interface 2 Interface 1

W W

Interface 3

W

Output Model 2

Output Model 1

System

S

upported by M

e

Pre

Mas

ter

Ing

est

Pre

sen

tati

on

Ingestion Process

Ingest Distribution Process

Master DB 1

Master DB 2

K

K

Data Distribution Process

Presentation

Re-Dist. Edge

K

K K

W

External Data Feeds

K

F

Pre-Render 2 Pre-Render 1


System View - Ingestion

12

My System

Ingestion Process

Ingest Distribution

K

External FeedsFTP

Binary Format 1

Internal FeedWeb Service

XBRL

Frame Handler

Line Arbitration Ex

Line Arbitration Int

Message Assembly Line

A

Incoming

Message LoggerA

AMultiple Data Models –Normalized Protocol

Normalization

Con

trolle

r

Message Transformer

Symbol Translator

Logger

Common Format Logger

Symbology Translation Service

Field Lookup Translator

A

My XML


Logical Sequence Diagram

13

sd Ingest

External Feed

Frame Handler: Line Arbitration

Frame Handler: Message Assembly

Frame Handler: Message Logger

Normalization: Ingestion

Distribution

Arbitrate

Full Message?

Log Message

On-pass Message

On-pass Message

Frame Received

Frame Received

REF: Normalize

On-pass frame

PAR

PAR


Deployment

14

DM

ZC

ore

Co

llec

tio

n

INGEST Hardware LBHorizontalQuantity = 4

Intel2x1.2Ghz 16MBSolaris 8

Ingestion Process

Ingest Distribution Process

MASTER_DB ClusteredVerticalQuantity = 2

Intel8x1.8Ghz 64MBSolaris 8Oracle 10g

Master DB 1

Master DB 2

Data Distribution Process

PRE-REND1 Hardware LB

Horizontal

Unit = Render

Quantity = 4

IBM X366

4x3.66 Ghz 8GB

Linux AS4

Oracle 10g

PRE-REND2 Clustered

Vertical

Unit = Render

Quantity = 2

IBM X366

4x3.66 Ghz 8GB

Linux AS4

PRESENTER Software LB

Horizontal

Unit = Render

Quantity = 8

IBM X280

2x2.8 Ghz 8GB

Windows 2003

Presentation

DF_EDGE Software LB

Horizontal

Quantity = 2

IBM X280

2x2.8 Ghz 8GB

Windows 2003

Re-Dist. Edge

Pre-Render 2 Pre-Render 1

IIS IIS


Site Diagram

15

DM

ZC

ore

Co

llect

ion

Site 1 (Live)

DM

ZC

ore

Co

llect

ion

Site 2 (Live)

INGEST

Data feedSource

A

INGEST

Data feedSource

B

Data feedSource

B

TCP: 9090 (Source A)

Master DB Master DB

SANSTORAGE

SANSTORAGE

SRDF

TCP:4040 TCP:4040

DB Synchronization(Oracle)

PRE_REND2

Fiber Channel

Fiber Channel

Fiber Channel

Solaris NFS2049 Oracle SQL

4000

PRE_REND1

Oracle SQL4000

DF_EDGE

HTTP15100

HTTP17100

PRESENTER

HTTP15100

HTTP17100

HTTP:80

PRE_REND2

Fiber Channel

Solaris NFS2049Oracle SQL

4000

PRE_REND1

Oracle SQL4000

DF_EDGE

HTTP15100

HTTP17100

PRESENTER

HTTP15100

HTTP17100

HTTP:80

Load Balancer

F5 Load

Balancer

F5

Heartbeat

HTTP:80

www.mysite.com/index.html

The Internet


Node Diagram

16

D1-C3-Firewall-AHeartbeat

Heartbeat

Heartbeat

Ed

ge

(D

MZ

)W

eb

Tie

r (D

MZ

)C

ore

Sit

e `

INGEST01-A

SANSTORAGE

PRE_REND2-A

DF_EDGE15

HTTP:80www.mysite.com/index.htmlThe Internet

Cisco Pix FirewallModel: Cisco FWM ver 7.2Clustered

Cisco Switch: 65xxBandwidth: 100/FullActive/Active

F5 Big IP Load BalancerClustered

Cisco Switch: 65xxBandwidth: 100/FullActive/Active

7

31

A.B.C.D2

A.B.C.D1

Presenter D1-PRES-01 (07)

x4

A.B.C.D101-104

Presenter 2, 4, 6, 8D1-PRES-02-(08)

DF_EDGE2

A.B.C.D4

D1-DF01

D1-DF02

D1-C0-Firewall2D1-C0-Firewall1

D1-C3-Router-A

External VIPA.B.C.D

D1-C1-Router-B

Master DB-A


DC1-BackLAN 1VLAN B1A.B.C.D

External BACK LAN VIPA.B.C.D

D1-C3-Firewall-B

A.B.C.D3

A.B.C.D5

A.B.C.D105


Cisco Switch: 6509Bandwidth: 100/FullActive/Active

D1-C3-Router-B

D1-C2-Switch-A D1-C2-Switch-B

D1-C2-BigIP-AD1-C2-BigIP-B

D1-C1-Switch-A D1-C-Switch-B

D1-C1-Router-A

DC1-LAN 2A.B.C.D/E

D1-C3-Switch-BD1-C3-Switch-A

D1-B1-Firewall-AHeartbeat

D1-B1-Router-A

D1-B1-Firewall-B

D1-B1-Router-B

D1-B1-Switch-BD1-B1-Switch-A

D1-B2-Firewall-AHeartbeat

D1-B2-Router-A

D1-B2-Firewall-B

D1-B2-Router-B

D1-B2-Switch-BD1-B2-Switch-A

31

A.B.C.D1

PreRender1 D1-PREREND1-01 (03)

A.B.C.D3

42

A.B.C.D2

PreRender1 D1-PREREND1-02 (04)

A.B.C.D4

PRE_REND2-B

A.B.C.D11A.B.C.D10

Master DB-B

INGEST01-B

INGEST02-A

INGEST02-B

Fiber Channel

DC1-Core LAN 1VLAN Core1

A.B.C.D

External Source AFeed 1

External Source AFeed 2

To Site 2

Feed Cross-Connect From Site 2

Timeout=xxx


Node Diagram (Bottom)

17


Node Diagram (Top)

18


Resources

• Logical Architecture Drawing Guidelineshttp://pro.iankoenig.com/docs/LogicalArchitecturalDrawingGuidelinesv3.pdf

19

• Visio “Smart” shapeshttp://pro.iankoenig.com/visio.php

• Ian Koenig’s Bloghttp://blog.iankoenig.com/


SOA – 10 “Golden” Rules

1. SOA requires governance: The only way to control the complexity of an IT infrastructure built out of services is with a governance process based on "a well defined set of interface guidelines and policies“

2. Govern to the policies that matter: It is important to focus on policies that are critical to making the business work. Its easy to come up with 5,000 really good ideas, but pick the 50 “rules that matter” and govern to those. Having too many policies is just as ineffective as having none (maybe worse).

3. People don't communicate: Words aren’t enough to communicate architecture precisely. You need diagrams and words. No matter how large your documents are, you will miss something and weightier is not necessarily better. I recommend starting with a subset of UML tools for class diagrams and sequence diagrams to clarify problems and review meetings to describe the architecture without weighty documents. But every enterprise needs to tune this to its own culture.

4. Make governance easy and do it early: Since nobody likes being told after they have completed a project that they have done it wrong and need to do it over, integrate the policy management into the Software Development Lifecycle (SDLC) and automate as much as possible.

5. Reusability does not come cheap: Despite all the hype around SOA and reuse, building reusable services is expensive. "In fact, our rough calculations are that it is approximately 2.5x as expensive to make a module re-usable as not. Make sure you have 3 potential users of a service before you embark on the effort.

6. Interfaces are more important than implementation. A proper interface encapsulates its implementation, so get the interfaces (APIs) right first. Start with versioning policy and loose coupling ; then extend to items like parameter use and Data model design”.

7. Integration is more common than "green field: While there may be so-called "green field" architectures out there , I’ve never seen one and don't expect to. Many companies grow through acquisitions and accrete heterogeneous systems. SOA (through encapsulation and ‘separation of concerns’) is a good way to deal with this reality.

8. Identify ownership for every service: Every service in an SOA should have an owner. There are owners at two levels. Business owners are responsible for the business aspects of the service, including the cost of running it and its value proposition. Infrastructure owners are responsible for maintaining the service level agreements (SLAs), and making sure customers of the service are satisfied .

9. Be pragmatic: There are no perfect SOAs. There will inevitably be "deviations" from SOA best practices to meet the immediate demands of the business (your customers). Track deviations through the governance process and manage their eventual elimination “in the fullness of time”.

10. It's all about governance: SOA requires on-going governance to measure how far you are from your goals and whether you are converging or diverging. Through on-going governance architects learn where the SOA needs to be enhanced and what new development is needed to solve problems in the ever changing IT landscape.


Is This What Governance Feels Like To You?

enterprise architecture governance november 2008 ian koenig

Documents

governance slide

technology governance

copyright ian koenig

ian koenig slide

principles standards

defined standards

industry standards

standards compliant