Enterprise Architecture Governance November 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 START DESTINATION You are here Death by Governance I.T. Anarchy I.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 3 rd 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: 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: 9

Copyright © Ian Koenig The Perspective View 10

Copyright © Ian Koenig System View

Copyright © Ian Koenig System View - Ingestion 12

Copyright © Ian Koenig Logical Sequence Diagram 13

Copyright © Ian Koenig Deployment 14

Copyright © Ian Koenig Site Diagram 15

Copyright © Ian Koenig Node Diagram 16

Copyright © Ian Koenig Node Diagram (Bottom) 17

Copyright © Ian Koenig Node Diagram (Top) 18

Copyright © Ian Koenig Resources Logical Architecture Drawing Guidelines Visio “Smart” shapes Ian Koenig’s Blog

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.UML 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.Software Development Lifecycle (SDLC) 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”.APIs 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.service level agreements (SLAs) 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?