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?
Copyright © Ian Koenig 4
STA
RT
DESTINATIONYou are
here
Death by Governance
I.T . AnarchyI.T. Control
Headquarters
Don’t overshoot
Don’t overshoot – Death by Governance
Copyright © Ian Koenig
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
Copyright © Ian Koenig
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
Copyright © Ian Koenig 7
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”
Copyright © Ian Koenig
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.
Copyright © Ian Koenig
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
Copyright © Ian Koenig
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
Copyright © Ian Koenig
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
Copyright © Ian Koenig
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
Copyright © Ian Koenig
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
Copyright © Ian Koenig
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
Copyright © Ian Koenig
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
Copyright © Ian Koenig
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
Cisco Pix FirewallModel: Cisco FWM ver 7.2Clustered
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 Pix FirewallModel: Cisco FWM ver 7.2Clustered
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
Copyright © Ian Koenig
Node Diagram (Bottom)
17
Copyright © Ian Koenig
Node Diagram (Top)
18
Copyright © Ian Koenig
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/
Copyright © Ian Koenig 20
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.
Copyright © Ian Koenig 21
Is This What Governance Feels Like To You?
Top Related