Presentation is loading. Please wait.

Presentation is loading. Please wait.

Interoperability. Jason Hogg Group Architect Solution Engineering Enterprise Services Microsoft Corp.

Similar presentations

Presentation on theme: "Interoperability. Jason Hogg Group Architect Solution Engineering Enterprise Services Microsoft Corp."— Presentation transcript:

1 Interoperability

2 Jason Hogg Group Architect Solution Engineering Enterprise Services Microsoft Corp.

3 Goal – Walk through an end-to-end approach for capturing and describing business and IT capabilities and mapping between them with traceability Approach – Briefly review processes for capturing and prioritizing business capabilities – Discuss the need to map from a business capability to Technology Enablers and the lack of standardized approaches for capturing and describing these – Describe the role of Reference Models, Reference Architectures and Reference Implementations in describing the Technology Enablers – Exemplify the approach for the BI Domain Work-In-Progress – Some of the concepts discussed today are already in-use by Microsoft Strategy Advisors – Others are work in progress have been tested in limited scenarios Objectives

4 Responsible for designing and building reusable solutions that Microsoft Services (and partners) can use on customer engagements We have partnered with other teams at Redmond including Architectural Governance and our Advisory Services teams Architectural Governance can benefit from understanding adherence (or not) to prescribe solution architectures Important for us to have processes, tools and models that allow us to capture IP from multiple field engagements Microsoft Services Solution Engineering Team Perspective

5 Engagements Span Organizations - – Our Services Division or organized into three main groups of consultants: Advisory Services Consulting Services Premier Services – Many of our engagements also includes partners EPG Go-To-Markets – Marketing organization has “workload” specific marketing initiatives – Workloads are often times lead to a consulting engagement Products vs Solutions - Microsoft is traditionally seen as a product company – If a customer has a problem – we jump directly to a product to fix it – Reality is of course much more complicated than that Consistency and Traceability - Establishing consistency around capturing and describing our business and technical requirements and designs is critical to our ability to succeed Microsoft Services Perspective

6 Prioritization – How do we prioritize investment (people / process / technology) in capabilities across a portfolio of capabilities in order to maximize business impact? Gap Analysis – How do we find gaps in our current portfolio that if filled could increase business impact? Overlapping capabilities – How do I identify overlapping capabilities that may exist in different areas / applications many of which will almost certainly manage different datasets? A Business Perspective

7 Demonstrate impact – How do I demonstrate impact in order to drive support around prioritization and budget allocation? Platform selection – How do we select the right solution where a gap is identified and prioritized? Business alignment – How do I show alignment with strategic goals of the business? A Technical Perspective

8 MSBA to identify what change to make BDN to understand why the changes must be made Project level alignment around how the projects will make the changes Microsoft Advisory Services

9 Microsoft Services Business Architecture (MSBA)

10 Benefit Dependency Network (BDN)

11 MSBA provides the common vocabulary for describing a businesses capabilities BDN’s provide a means of understanding relationships between capabilities, corporate strategies and technology enablers But… We lack a standard way to rationalize the IS/IT (Technical) Enablers The Problem

12 Definition – Technology Enablers are the Services (application and infrastructure capabilities) delivered by IS / IT departments supporting the needs of a business capability – Technology Enablers are delivered using People / Process and Technology Technology Enabler Patterns? – Archetypical technology enablers should exist capturing commonality and variability identified across multiple engagements – Where are they being captured? Reference Models Reference Architectures Archetype Patterns … Or Customer Specific Implementations… Technology Enablers

13 Microsoft “Reference Architectures”

14 Requirements – Establish a standardized vocabulary for core concepts within and across domains – Capture and express commonality and variability within a domain based on recurrent experience – Support composability – allowing technology enablers to work with other technology enablers – Described at multiple levels of abstraction Technology independent Platform independent Product specific – Incorporate a means of transforming between such levels of abstraction – Standardized schema for describing technology enablers – thus allowing libraries of these descriptions to evolve Describing Technology Enablers

15 Proposal – Reference Model – to standardize vocabulary within a domain – Reference Architecture – to standardize architectural descriptions of technology enablers – Reference Implementation – to standardize “sample” implementations of a reference architecture Describing Technology Enablers

16 A Reference Model* identifies significant entities that exist within a domain and relationships between such entities, thus providing a standard vocabulary for a particular domain. A Reference Model is technology neutral - intentionally abstract of products or technologies allowing for a stable view of the decomposition of a domain. Reference Model Definition

17 A Reference Architecture* provides a templatized description of the architecture of a particular solution domain. A Reference Architecture prescribes functionality that is core to that class of system, architecturally significant design decisions and common points of variability which must be considered during system design. Reference Architecture Definition

18 A Reference Implementation is a working application designed to demonstrate how a Reference Architecture can be applied to some subset of a real-world scenario. Unlike a sample application reference implementations are created with the intent that code illustrates proven engineering practices. There are two kinds of Reference Implementations: – Exemplar Reference Implementation - working applications designed primarily to demonstrate how an RA can be applied to some subset of a real-world scenario. – Baseline Reference Implementation - working applications designed to be customized in order to meet the specific needs of a domain. Unlike an exemplar RI a Baseline Reference Implementation is intended as a starting point for further customization. Reference Implementation

19 RM and RA Example

20 IEEE1471 – Conceptual Model for Describing Architecture (RM, RA and RI’s) A system has stakeholders A stakeholder has concerns Concerns are satisfied by models A viewpoint specify types of models A model has a defined structure A view uses instances of models A system has an architecture An arch is described using an AD

21 IEEE Architectural Frameworks A.F. aggregates A.Vp

22 Reference Model Architecture Framework

23 Main Viewpoints – Industry Domain Viewpoint – Microsoft Product Domain Viewpoint – Feature Dependency Viewpoint Reference Model Arch. Framework Industry Domain Viewpoint Microsoft Product Feature Model Office Feature Model SharePoint Feature Model SQL Server Feature Model System Center Feature Model Windows Server Feature Model Windows Client Feature Model

24 COTS vs Custom LoB – Custom LoB RA’s typically focus on how to structure an applications architecture and key design patterns which the developer should follow – COTS applications are typically focusing on the “logical features” typically associated with an application – and how these map into “physical features” within a particular product The Role of Feature Models in RA’s

25 Existing attempts to model domains (such as Oasis SOA RM) had weak / inconsistent approaches to modeling the domain Feature-oriented approach has been used extensively in industry and academia since the FODA (Feature Oriented Domain Analysis) method was introduced in 1990 by the Software Engineering Institute (Ref SEI) Feature-oriented design and architecture approach based on an explicit definition of a feature – A prominent or distinctive user-visible aspect, quality, or characteristic or a software system or systems Lead to development of MSPL – the Microsoft Services Product Lines notation Feature Modeling Background

26 MSPL Overview MSPL is intended to describe the sets of features necessary to deliver a product or classes of products – making it a good complement for the reference architectures where a notation like MSPL can be used to describe application / platform / infrastructure archetypes An MSPL or UML like notation will be required inside the reference architectures when describing relationships between features when solving a problem – requiring the capability to express optional and mandatory relationships and multiplicity etc

27 MSPL: Alternative Features modeling Graphical notation based on FODA process Allows specification of – Core and mandatory feature relationships – Cardinality – Tracability to requirements – Implementation within components – etc

28 MSPL Static Modeling

29 Reference models comprising of the set of logical features associated with a particular domain provide a valuable tool for reverse engineering applications against a standard taxonomy Allows for identification of: – Recurring features which could be turned into shared components – Recurring features managing different data sets – identifies areas where inconsistent data management practices may exist – … The Role of Features in Portfolio Mgmt

30 Reference Architecture Architecture Framework

31 Software Architecture (4+1 or n+1) Main Viewpoints – Application (Logical) Viewpoint – Deployment (Physical) Viewpoint – Process Viewpoint – Developer Viewpoint – Use Case Viewpoint Additional Viewpoints – Data – Integration – Operations – …

32 Main Viewpoints – System Viewpoint – Application – Deployment Viewpoint – Process Viewpoint Additional Viewpoints – Data – Integration – Operations – … Software Reference Architecture

33 Architecture Framework Library IT Service Viewpoint Compute Viewpoint Network Viewpoint Storage Viewpoint Operations Viewpoint Management Viewpoint Deployment Viewpoint Requirements Viewpoint System Viewpoint Application Viewpoint Integration Viewpoint Data Viewpoint Process Viewpoint Business Capability Viewpoint Business Strategy Viewpoint Business Architecture Framework Software Architecture Framework Infrastructure Architecture Framework

34 Business Intelligence Dashboard & Scorecard Archetype

35 BI Reference Model Analysis Subsystem OLAP Authoring Tool Cube System Analysis Management Subsystem Analysis Storage Subsystem Data Mining Subsystem Data Subsystem Extract Subsystem Transformation Subsystem Load Subsystem ETL Management Subsystem Reporting Subsystem Report Authoring Tool Report Rendering Subsystem Report Subscription Subsystem Report Data Manager Report Catalog Manager Report Management Subsystem Delivery Manager Report Monitoring system Client Subsystem Web ClientOffice ClientRich ClientMobile ClientRich Internet Application (RIA) Client Presentation Subsystem Site Subsystem Page Layout Subsystem UI Control Manager Print Manager Presentation Format Manager Alert Manager

36 Microsoft Services Business Architecture (MSBA)

37 Benefit Dependency Network (BDN)

38 D&S Archetype: System View

39 D&S Archetype: Deployment View

40 D&S Archetype: Application View

41 D&S Archetype: Process View

42 BI Reference Architecture IT Service Viewpoint Compute Viewpoint Network Viewpoint Storage Viewpoint Operations Viewpoint Management Viewpoint Deployment Viewpoint Requirements Viewpoint System Viewpoint Application Viewpoint Integration Viewpoint Data Viewpoint Process Viewpoint Business Capability Viewpoint Business Strategy Viewpoint Business Architecture Framework Software Architecture Framework Infrastructure Architecture Framework

43 What worked – RM now established as standard vocabulary for BI deliverables – RA has been successfully used for both brown field and green field customer scenarios – We are building a number of other RMs and RAs to support SOA / Integration, SharePoint, … – RM & RA schema definitions have been agreed upon – and work is now in process for wiring the viewpoints and models together Lessons – Significant discipline required to create Reference Models and Reference Architectures in a coherent and standardized manner – Reference Model captured logical features and definitions of each feature – but relationships between feature areas requires more work – Vision is realizable but - will require a significant investment in disciplines and deliverables not usually heavily invested in BI – What worked and what didn’t work?

44 Shown how to capture the functions relevant to a business and how to prioritize those suited for technical investment Shown how to map from these standard business functions to Technology Enablers Shown how to standardize terminology in a domain using Reference Models Shown how to define standard libraries of Technology Enablers using Reference Architectures and Archetypes Demonstrated application of these concepts to the BI Domain Summary

45 Utilize Microsoft Advisory Services for BI – Skand Mittal Microsoft Advisory Services (MSBA and BDN) – Martin Sykes Concepts – Jason Hogg Call To Action

46 MS Team – Jason Hogg, Brant Zwiefel, Fabio Bagatin, Michael Regan, Shaun Hayes, Joshy Joseph, Alejandro Miguel, Brad Clayton, Karsten Smet BI Team – Alejandro Miguel, Srinath Vasireddy, Skand Mittal BI Services Team – Robert Skoglund et al Microsoft Executive Sponsors – Michael Kropp, Doug Laundry, Rick Maguire, Ulrich Homann MSIT Team – Nick Malik, Bob Sturm, Gabriel Morgan MS ITAP Team – – Brad Cooper, Martin Sykes, Warwick Holder, Rick Maguire Acknowledgements

47 Microsoft Services - Microsoft Services Architecture and Planning – J. Neighbors, “Software Construction Using Components”, PhD. Thesis, Dept. of Information and Computer Science, U. of California. Irvine, K.C. Kang et al., Feature-Oriented Domain Analysis (FODA) Feasibility Study, tech. report CMU/SEI-90-TR-21, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, – Philippe Kruchten, Rational Software A Survey of Software Architecture Viewpoint Models, Nicholas May MSPL – Fabio Bagatin, Architect, Microsoft Services MSBA – Microsoft Services BDN – Cranfield University, UK Jason Hogg – References

48 Discussion


50 Business Capability - A business capability is a stable component of the business architecture describing "what" a company does vs. "how" it does it. A logical application feature is a prominent or conspicuous trait of a software application or solution as described from the user's point of view. Viewpoint - determines the resources and rules for constructing a view. View - a representation of a whole system from the perspective of a related set of concerns. Additional Terms

51 It Isn’t for Lack of Standards International & Regional Standards Bodies IT Industry Microsoft Worldwide Services BSI ITU ASTM ANSI UNSPSC IEC ARTS (Retail) FASB SEC JSOX ASCA Sarbanes Oxley CEN HL7 NRF (Retail) ISO SL6 – Industry RA’s BI RM and RA ITAP MAPF E2E Scenarios Global Arch Fx SOA RM + RA GP DDC RAService Maps MSBASure Step SDM SE Architectural Model SAT Guides P&P Meta-FrameP&P App Arch Guides MSF MOF Software Factories Oslo VS 2010 Arch Oasis SOA RM + RA MDA UML IEEE 1471 ZachmanTOGAF CORBIT ITIL Patterns Web Service Standards

Download ppt "Interoperability. Jason Hogg Group Architect Solution Engineering Enterprise Services Microsoft Corp."

Similar presentations

Ads by Google