Foundation Reference Model IASA Taxonomy Workshop March 23

Foundation Reference Model IASA Taxonomy Workshop March 23, 2006 The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Presenters Richard Hubert VP IASA Education, IASA Bo. D, Co-director IASA Europe Convergent Architect, Certified Master Convergent Engineer Angela Yochem VP of EA at a top 10 US Bank Author and public speaker IASA Fellow Oliver Sims Independent EA Consultant Over 30 years experience in IT Author and magazine contributor IASA Fellow The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Agenda • • Introduction to the IASA Foundation Reference Model (FRM) The FRM § § § • The IASA Glossary (Ontology and Terms) Usage Scenarios and Examples The IASA Architectural Style Metamodel (ASM) Framework Ø Foundation Concepts Ø ASM Best Practice The FRM Document Set The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Architecture and the Architecture is 'large scale design' The architect must 'manage the big picture'. This is not just technology. It means constantly integrating and managing an interwoven set of things that have complex but real relationships as a primary skill. § § Process and Organisation aspects Operational aspects Business aspects Technology aspects Orchestrating this weave, or the 'glue' effectively across many systems and organisations is what makes a good architect. This 'glue', the orchestration, and overall 'gestalt' relationships is what the IASA F&T Workgroup is charting out for the first time. The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

But not Everything is IT Architecture … – That’s Just the Point! However, IT-architecture permeates the entire system life cycle § Interwoven with many development and technical preparation tasks § But architectural threads in the overall 'fabric' are not clear… And roles and skill-sets of IT experts today are obscure and confusing The IASA FRM distinguishes between architectural processes (roles, skills, orgs) and other processes (roles, skills, orgs) The architectural process must be defined and visualised § If you can’t see it, you can’t manage it, teach it or automate it § The key to architecture-centric design § Another case of the 'Designer’s Paradox' The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

The FRM Workgroup’s Major Goals Add a 'global architectural order' and 'the big picture' to the existing concepts: chart the largely uncharged territory … Focus on 'the business of IT architecture' in its own right Be as non-prescriptive as possible We had to figure out how to best categorise and order all these 'architectural things': 'No reference frame, no order' FRM orientation Architectures & Architectural Approaches The IASA Architectural Style Metamodel The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Evolve from Project Blobs to More Holistic Architectural Approaches Microsoft IASA Workgroups IBM/ADS Convergent Architecture Architectural Style influences RP-Definition IEEE 1471/TOGAF… SAP Unisys COSM VP/RP-Req EDS influences/basis = Unit. Ops, at various levels of abstraction IASA Foundation Reference: Metamodel and IASAF sample for (creation, use, care, feeding) of Architectural Styles RP = Defined Reference Platform defines Mixed or 'non' style systems RP-Kit Corporate Architectural Style Architecture Centric Development Centers Blobs The Corporate IT-Landscape VP/RP-Instance 'All projects use this' Goal: From ad-hoc blobs to holistic architecture The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

FRM Concepts The FRM takes a holistic approach to today’s complex network of architectural concerns § Terms and Ontology Ø Artifact, Application, Platform, etc. Ø Difference between Terms and Ontology § Scenarios Ø Personas Ø Usage Ø Perspectives § Architectural Style (Arc. S) Ø Meta. Model (ASM) and Samples Ø Unit Operations (Unit. Ops) and Samples § Incorporates IEEE 1471 concepts FRM Deliverable 1: Glossary/Ontology, Primer (Scenarios) FRM Deliverable 2: ASM, IASAFramework (Unit. Ops, guidelines, samples) The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Glossary Terms and Ontology Glossary describes terms and common usage patterns § 100+ defined terms § The relationship between terms § How terms apply to concerns of various roles The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Scenarios Personas, Perspectives, and Usage Scenarios illustrate areas of common architectural concern § Used as a starting point for FRM adoption by architects § Describes how to implement the FRM at the project, program or enterprise level § Depicts pre- and post-adoption cases (First Project Architecture etc. ) § Usage models describe the application of FRM Personas describe the nature of a role and corresponding architectural interests § 21 Initial Roles/Actors: Architects (Application, Business, Enterprise, Platform, etc. ), various Stakeholders (VP Sales, Technical Lead, Business Analysts) and the like § Used to illustrate relationships between roles, terms and the FRM Perspectives provide context within an entity or entities § e. g. Corporate Architectural Style (CAS) Examples The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Scenarios Personas, Perspectives, and Usage Potential usage scenarios of the FRM – examples: § § Ad-hoc Project Architecture (First Project Architecture) First FRM Usage Project Architecture Program-level FRM Adoption Scenario Enterprise-level FRM Adoption Scenario Ø Governance Incorporation Ø Infrastructure Impact Ø Capability and Resource Organisational Impact Ø Business Architecture Incorporation The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Usage Before: Project Architecture Unstructured Architecture Effort § Often led by force of personality § Very little repeatability outside of SDLC bounds § Requires massive education effort – terms, artifacts, style The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Usage After: First FRM Usage Project Architecture Initial Adoption of FRM-based Approach § First step in repeatable, predictable and measurable architecture efforts § Initial education effort aided by FRM materials § Project level adoption requires strong champion The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Usage After: Post-FRM Project Steps Adoption of FRM-based approach in a wider scope § Enterprise architecture effort often follows successful project architecture efforts Ø Typically unsuccessful due to perspective gaps § Recommended approach is to scale to a program or portfolio level before planning an enterprise architecture practice The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Usage Program-level FRM Adoption Scenario Adoption of Architectural Style across a logical grouping of projects/initiatives § Facilitates program-level optimisations § Assumes technical ownership at a program level The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Usage Enterprise-level FRM Adoption Scenario (Excerpt) EA Practice Definition § Considerations cross functional and line of business boundaries § Assumes continual evolution § Includes governance model § Infrastructure and operational impact § Capability and organisational impact § Business architecture incorporation § Recommended post program-level adoption The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

IASA FTWG Deliverables The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Deliverables: Packet 1 Packets are targeted deliverables § Designed to reduce the complexity by giving proper information at the appropriate level § Divided into 2 packets Ø Packet 1 is for architects (i. e. practitioners) Ø Packet 2 is for vendors and consultancies for alignment purposes (tools and process providers) Packet 1 includes the Scenarios and Glossary (Terms and Ontology) The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Glossary Terms and Ontology Glossary describes terms and common usage patterns § How terms apply to concerns of various roles § The relationship between terms § 100+ defined terms The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Glossary Terms and Ontology describes common usage patterns § How terms apply to concerns of various roles § The relationship between terms A Technical Architecture specifies the software technology and quite possibly the hardware technology, to be used by one or more development projects. It may well include patterns and designs that address the 'ilities and 'iences. It may also include generic specification of the required modularisation strategies for Business Function is that behavior of an IT System that is specific to the business in which the IT System operates. Business Function is function that helps a person or requesting program to perform a specified task within the enterprise. Normally this means things like order entry, capacity planning, chip design or oil refinery process automation. However, people working within IT also perform business functions. For example, a network manager's business function is the business of managing a network; a programmer's business function is that function that enables him or her to develop and test programs. In Traditional Applications, Business Function is constrained by Technology Function such that certain structures and interactions are advised (the degree of constraints is defined by the human and management dynamics of the development team - or, in other words perhaps, project governance). The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Glossary Ontology Example - Virtual Platform The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Glossary Ontology Example Architectural Concern The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Deliverables: Packet 2 contains the IASA ASM Framework (ISAF): § The Architectural Style Metamodel (ASM) § Best Practices § IASA Unit. Ops The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

The IASA Foundation Reference is based on a reference Metamodel for Architectural Styles Architectural Style (may be represented as IEEE 1471 Viewpoint Library) PAREs Architectural Principles of the Style (key design priorities: 'ten commandments') key relationships Process Methodologies Designs, Patterns influences Process Aspects (key process areas/representations) key relationships influences Structural Aspects (key design areas/representations) influences Development Tools Tool & Dev. Platform Aspects (=>Software Production Lines) influences Technologies Technical Infrastructure & Runtime Technologies The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Arch. S Meta. Model (ASM) The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Best Practice: Kinds of Architectural Style The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Architectural Style - Benefits § Builds on (evolves) previous concepts of the same name § One Arch. S is specific to a given family of systems Ø e. g. Client/Server, Process Control, Real-Time Distributed § Context sensitive Ø includes scope definition Ø considers constraints Ø Allows for different 'levels' – General, Corporate (CAS), Domain (DAS), … § A Conceptual Framework Ø Can be applied to most (all? ) architectural endeavors Ø When formalised, becomes guide for best practices Ø Wide application – Apps, Middleware Infrastructure, Operating systems, … § Covers most (all? ) architectural concerns Ø Principles, Structural, Infrastructure, Process, Tools § Unit. Ops – instructions for how to create a lower level The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Architectural Style - Unit Operations (Unit. Ops) § Key components of Arch. S design/evolution/maintenance § Architectural-level processes Ø Not to be confused with the software development process itself Ø Not to be confused with the Process Aspect of an Arch. S § Can evolve (they are also part of a holistic big picture) The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Unit Operation (Unit. Op) - Examples ASM Gen Arch. S CAS ASM Unit Ops: Gothic Cathedrals Style Define AP: List the major traits, symbolism, message, qualities AP: Provide symbols of the religion: spires, crossshape, tapered arches, overly dimensioned, high ceiling, thin walls, rose window, etc. Define P: Define the processes for the planning org. and on the construction site, resource mgmt… Define S: Define how you will represent your processes of type defined in 'P: '. Define T: Define how you will automate and support the processes (P, S) Define I: Define the targeted types of materials/technologies P: Use pole measures consistently, Use falsework arches, make all arches in arcade identical S: A pole measure, the falsework arches, corresponding stone templates. T: Mainz type scafolding, Belgian Pulley system, Falsework racks, . . I: For best results: Sandstone, Oak, Leadglass AC. DC Convergent Architecture Business Systems IBM ADS/PAI Style AP: Integrate business, project, system processes via CE AP: Link functional and concepts, Machine shop metaphor, operational aspects. Intense RASC, Conceptual Isomorphism, focus on non-functional Component Metamorphosis requirements, Leverage highly integrated IBM technology, P: BPM with CRC/OPR techniques, scaleable asset deployment. Component Metamorphosis procs, OPR modeling of the IT-Org P: The process for business, processes, OPR/MDA models for 4 functional, operational modeling, tier architectures in J 2 EE or. NET the CCM process, testing, staging… S: UML modeling style sets for OPR/RASC model refinement using S: MDA modeling style sets Convergent Components. MDA (Metamodels, profiles, Cartridges to J 2 EE or. NET… transforms) for each model set, the UML/ADS models and T: Arc. Styler or identically documentation etc. configured Rational RSM or VS. Net T: Rational RSA with Subversion CCM, Web. Sphere MDA package, I: J 2 EE or. NET infrastructure PAI corresponding to the MDA cartridges I: PAI Infrastructure The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Next Steps • Sub-workgroups now activated for each deliverable of the FRM • Sub-workgroups being recruited § For configuration/mapping of an FRM Architectural Style based on existing architectural programs (IBM, EDS…) • April: first early release to IASA review teams • Thereafter (depending on review results) § First release of FRM § May take a few months since extensive and voluntary effort. • Thereafter, based on FRM: § Many derivative IASA workgroups § Educational/Acknowledgement program. The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

You Too can Contribute! • Contact your local IASA Chapter… § Review working group deliverables § Get involved in sub-groups § Attend IASA events Ø Monthly gatherings Ø Webinars, summits, etc. • If you have an opinion, make it heard! The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Foundation Reference Model IASA Taxonomy Workshop March 23, 2006 The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

E. g. Gen-Arch. S, Structural Aspects Note: not only UML. Style specific. The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

E. g. Gen-Arch. S, Structural Aspects The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Example Unit. Ops… (architectural processes) ASM Gen Arch. S IBM ADS/PAI Architectural Style. Unit. Ops Gen. Arc. S=>CAS AP: Adapt/extend statements of principles to the actual corporate or organisational context. P: Add local organisational types, nomenclature, company information flows, company role names, company process interfaces or technology specifics – as follows. S: Add company policy documents, legacy structures to be addressed, modify/deprecate MDA modeling styles to handle process adaptations – as follows. T: Adapt Virtual Platform to automate modified/added structures and processes -- as follows I: Install, test, integrate the PAI reference platform into the corporate IT infrastructure as follows: reference installations, tool integration CAS AC. DC IBM ADS/PAI Corporate Architectural Style for A 1 Corp. AP: Our operational monitoring will be defined and driven by models. Our governance org. now measures nonfunctional requirements via explicit PAI staging tests. P: Additional process synchronising with our existing CVS repository schemes. Processes to MDA-integrate our five existing DBMS. Operational montoring process adaptation. Corporate tool and reference platform installation processes. S: CVS repository scheme mappings, Physical data models and automated MDA transformations. T: Extensions/adaptations for P’s and S’s above. Virtual Platform integration. I: PAI reference platform/application installation as part of Virtual Platform. The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

e. g. Arch. S Tool Aspects (Virtual Platform) The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

e. g. Arch. S Process, Structural and Tool Aspects (Virtual Platform) The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006

Example Unit. Ops… ASM Gen Arch. S IBM ADS/PAI Architectural Style. Unit. Ops CAS => AC. DC AP: Apply principles to project-specific context. P: Polish development process for the precise project context: Add org/dept names, specify company process instances, reporting targets, specific system/server instances used. . . S: Polish structural resources as required by the processes and to to precise project context: e. g. Software licensing, software kit locations, e-mail lists, repository locations, reporting lists, document templates, node identification and infrastructure versions. T: Adapt the Virtual Platform to automate polished structures and processes. Package as part of installable Virtual Platform I: PAI becomes part of the installable Virtual Platform CAS AC. DC IBM ADS/PAI based AC. DC AP: The IT-Ops org manager is working with us and two other AC. DCs to test the generated operational components. Non-functionals such as availability, performance will tested by the Architecture org at staging time… P: The development process including, ITorganizational interactions and operational lifecycle is tracked and driven via a process management system available to each developer in the AC. DC tool interface. S: The artifacts and infrastructural resources are available to each developer in the AC. DC, many of these (such as DBMS mappings and CVS synchronisation) are available via the AC. DC tool interface. T: The AC. DC specific software production line is an integral part of the Virtual Platform and is easily installable the defined infrastructure. I: PAI reference platform for development, testing etc. is an integral part of the installable Virtual Platform. The use, disclosure, reproduction, modification, transfer, or transmittal of this work without the written permission of IASA is strictly prohibited. © IASA 2006