Download Presentation


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Download Presentation

  1. 1. Montages Partner Meeting - Zurich – Nov 4-5, 2006 Integrating BPM and SOA with Model Driven Solutioning (MDS) Michael Guttman [email_address]
  2. 2. Relation to MAMA MAMA Service Methodology MAMA Service Methodology MAMA Service Methodology MAMA Service Methodology Open Source Software Montages Software Service Automation Framework Closed Source Software Montages Software Service Automation Technologies Requirements Management Change Management Transitions Management
  3. 3. Agenda <ul><li>The Problem </li></ul><ul><li>BPM and SOA </li></ul><ul><li>Applying MDA </li></ul><ul><li>Transitioning </li></ul><ul><li>Model Driven Solutioning (MDS) </li></ul>
  4. 4. The Holy Grail of Corporate Computing <ul><li>Business conditions change </li></ul><ul><li>Business efficiently identifies new needs and opportunities </li></ul><ul><li>Business and IT efficiently specify new solutions </li></ul><ul><li>IT efficiently implements those solutions </li></ul><ul><li>Business reaps associated rewards </li></ul><ul><li>Go to 1 </li></ul>
  5. 5. Key Elements of the Holy Grail <ul><li>Time-to-market </li></ul><ul><ul><li>‘ Timed’ to market </li></ul></ul><ul><ul><li>Main strategic advantage </li></ul></ul><ul><ul><li>Critical for business buy-in </li></ul></ul><ul><li>Solutions quality </li></ul><ul><ul><li>Fitness to purpose </li></ul></ul><ul><ul><li>Performance/ Availability </li></ul></ul><ul><ul><li>Consistency/ Integration </li></ul></ul><ul><ul><li>Adaptability </li></ul></ul><ul><li>Lifecycle costs </li></ul><ul><ul><li>Cradle to grave </li></ul></ul><ul><ul><li>Mostly post-development </li></ul></ul><ul><ul><li>Continuous integration </li></ul></ul>
  6. 6. The Holy Grail Sounds Simple Enough, But…. <ul><li>Business does not describe its needs and opportunities in a consistent way </li></ul><ul><li>Business and IT speak very different ‘solutioning’ languages </li></ul><ul><li>IT does not follow consistent processes for creating, acquiring, integrating and customizing software </li></ul><ul><li>IT projects (and resulting software) are ‘balkanized’ into silos </li></ul><ul><li>Existing silos and layers of legacy software, hardware and ‘muddleware’ compound all of the above. </li></ul>
  7. 7. Where Have We Gone Wrong? <ul><li>Not for lack of trying – but too many uncoordinated initiatives </li></ul><ul><li>Top-down ‘big-bang’/‘next big thing’ approaches with poor follow-through </li></ul><ul><li>Lack of a truly ‘holistic’ and incremental approach that covers all solutioning activities </li></ul><ul><li>Focus on tools and technology, rather than process, organization and content </li></ul><ul><li>Project-centric – rather than program-centric – planning, budgeting and governance </li></ul>
  8. 8. Can We Get Back To The Right Path? <ul><li>Maybe – no guarantees </li></ul><ul><li>No one tool, process, software package or vendor provides ‘the answer’ </li></ul><ul><li>To be successful, any new approach needs to be iteratively customized over time </li></ul><ul><li>Successfully adopting and adapting new approaches requires a well-organized transition program </li></ul>
  9. 9. The New Holy Buzzwords <ul><li>BPM – Business Process Modeling </li></ul><ul><ul><li>Identify the key elements of the business and their relationships </li></ul></ul><ul><ul><li>Use these to model ‘as-is’/‘to-be’ business processes </li></ul></ul><ul><ul><li>Promise: the business becomes more aligned and “agile” </li></ul></ul><ul><li>SOA – Service-Oriented Architecture </li></ul><ul><ul><li>Break down current/future computing systems into reusable ‘services’ </li></ul></ul><ul><ul><li>Make these services widely available on a standardized ‘enterprise services bus’ (ESB) </li></ul></ul><ul><ul><li>Promise: IT becomes more aligned and “agile” </li></ul></ul>
  10. 10. BPM+SOA - The New Holy Grail? A P P L I C A T I O N S B U S I N E S S P R O C E S S E S B U S I N E S S S E R V I C E S C O M P U T I N G S E R V I C E S C O M P U T I N G A S S E T S Business Process Experts Systems Experts Business Domains IT Domains
  11. 11. BPM+SOA Expected Benefits <ul><li>Much more rapid time-to-market </li></ul><ul><li>Significantly improved solutions quality </li></ul><ul><li>Significantly lower solutions lifecycle costs </li></ul><ul><li>End-to-end traceability – requirements to deployment </li></ul><ul><li>Improved portfolio management and IT governance </li></ul><ul><li>Improved overall business-IT alignment </li></ul>
  12. 12. But is BPM+SOA Really Feasible? <ul><li>Can all of our various business units agree on a common set of business components to define their respective processes? </li></ul><ul><li>Can these high-level business components actually be transformed into a set of executable ‘business services’? </li></ul><ul><li>Can these business services really be transformed to ‘fine-grained’ computing services, and then to our real working systems, many of which are legacy and/or 3 rd party? </li></ul><ul><li>Are there reasonable mature tools and processes to support and manage all of the above? Will these integrate with the tools and processes we already have in place? </li></ul>
  13. 13. BPM to SOA – Is There A Bridge? BPM SOA ? Promotes consistency? Uses same language? Removes silos? Deals with legacy?
  14. 14. A BPM-SOA Bridge - What It Might Look Like <ul><li>Separation of concerns </li></ul><ul><li>Multiple viewpoints </li></ul><ul><li>Multi-level reuse </li></ul><ul><li>Precise information flows </li></ul><ul><li>Full traceability </li></ul>Business Analyst Solutions Designer Software Designer Implementation Models Deployable Software Business Models Solution Models Software Implementer
  15. 15. The Bridge - Could It Be MDA? Business Analyst Solutions Designer Software Designer Platform Specific Model (PSM) Deployable Software Computationally Independent Model (CIM) Platform Independent Model (PIM) Software Implementer
  16. 16. Model Driven Architecture (MDA) <ul><li>A set of open standards (OMG) defining the scope, content, creation of models for any business or technology domain </li></ul><ul><li>Standardizes the integration of modeling tools and management of model artifacts </li></ul><ul><li>Promotes a standards-based approach to integrating formal modeling into any software lifecycle process </li></ul><ul><li>Core Technologies include: </li></ul><ul><ul><li>UML, BPMN, MOF, XMI </li></ul></ul><ul><ul><li>CWM, EDOC, SPEM…. </li></ul></ul>
  17. 17. MDA – Some Common Myths <ul><li>Too complicated to learn. </li></ul><ul><li>Monolithic, waterfall; not ‘agile’. </li></ul><ul><li>Same problems as CASE. </li></ul><ul><li>Just UML with code generation. </li></ul><ul><li>Yet another way to sell more tools. </li></ul><ul><li>Isn’t going anywhere in the market. </li></ul><ul><li>Being replaced by BPM+SOA </li></ul><ul><li>………… </li></ul>
  18. 18. Will The Real MDA Please Stand Up? <ul><li>Based on proven best practices and open standards </li></ul><ul><li>Supported by 300+ OMG members </li></ul><ul><li>Widely implemented in commercial and open source tools </li></ul><ul><li>Applicable to a wide range of business and computing problems </li></ul><ul><li>Highly adaptable to different organizations, project types, toolsets, technologies, etc. </li></ul><ul><li>Supports all forms of development and deployment, including outsourcing and offshoring </li></ul><ul><li>Complements BPM and SOA </li></ul>
  19. 19. Using MDA To Enable BPM+SOA <ul><li>Define an enterprise architecture based on BPM+SOA </li></ul><ul><li>Model the information (metadata) flow from business models to executable software. </li></ul><ul><li>Establish a well-defined process to manage that flow. </li></ul><ul><li>Configure and manage a heterogeneous ‘tool chain’ to help support all of the above. </li></ul>
  20. 20. MDA – How It Fits with BPM+SOA New Business Models New Service Models New Implementation Models Reusable Business Model Patterns Reusable Service Model Patterns Reusable Design Model Patterns Deployed Software Components Reusable Deployed Components Business Requirements Enterprise Reuse Repository CIM PIM PSM Deployed
  21. 21. Assuming MDA Makes BPM+SOA Easier… <ul><li>Can it work in my company? </li></ul><ul><ul><li>Is it really worth the time, cost, effort and risk to realize the vision? </li></ul></ul><ul><ul><li>What will the ‘to-be’ state of our organization really look like? </li></ul></ul><ul><li>Whose going to do it? </li></ul><ul><ul><li>How do we manage/govern our organization’s transition to BPM+SOA and MDA? </li></ul></ul><ul><ul><li>How are we going to pay for all this? </li></ul></ul>
  22. 22. BPM+SOA Transition - Considering The Risks <ul><li>BPM+SOA with MDA sounds great, but it still looks risky: </li></ul><ul><ul><li>Significant re-tooling, re-skilling costs </li></ul></ul><ul><ul><li>Major impacts on many stakeholders </li></ul></ul><ul><ul><li>Challenging to roll out across a large organization </li></ul></ul><ul><li>Must be adapted to legacy processes, tools, and structures: </li></ul><ul><ul><li>Formal/informal; varying levels of maturity </li></ul></ul><ul><ul><li>Based on existing organizational structure </li></ul></ul><ul><ul><li>Based on existing tools and skill sets </li></ul></ul><ul><ul><li>Covering a wide variety of IT activities </li></ul></ul>
  23. 23. BPM+SOA Transition - Managing the Risks <ul><li>Set up a Center-of-Expertise (COE) </li></ul><ul><ul><li>Provides overall management and governance of the transition as multi-year ‘uber-project’ </li></ul></ul><ul><li>Organize transition activities into well-defined stages, phases, and tracks, where: </li></ul><ul><ul><li>Each stage results in new maturity level </li></ul></ul><ul><ul><li>Each phase (within a stage) has distinct transition deliverables </li></ul></ul><ul><ul><li>Each track is a major competency area </li></ul></ul><ul><li>Typical long-term transition timeframe: </li></ul><ul><ul><li>Large organization: 3-5+ years </li></ul></ul><ul><ul><li>Smaller organization 1-3 years </li></ul></ul>
  24. 24. Typical BPM+SOA Transition - Stages and Tracks Increased Maturity Levels Pilot Projects Enterprise Infrastruct. Transition Mngt. Enterprise Arch. Business Modeling Solutions Lifecycle Process Governance Foundation Establish COE Develop initial strategy/plan Establish core principles Define/deploy initial processes and governance Conduct initial training Define/deploy initial pilot solutions Demonstrate ROI with opportunistic projects Initial Refine transition strategy planning Define initial solution architecture and model taxonomy Enhance processes, tools, governance Expand training and mentoring activities Demonstrate reuse and ROI in full production projects Extended Develop detailed portfolio-based transition plans Refine enterprise and solution architecture Refine new processes, tools, governance Finalize training programs Systematically reengineer legacy, 3 rd party core systems Define new processes for all stakeholders Systematic Plan/execute transitions for all solution domains Standardize enterprise and solution architecture Standardize and proliferate training Finalize, standardize new processes, governance Complete reengineering of core systems
  25. 25. BPM+SOA Transition Phases (for each stage) Vision and Readiness Assessment Review Solution Architecture Pilot Solution 1 Pilot Solution 2 Pilot Solution 3 Transition Strategy and Plan Ongoing Program Management Review Review Review Review Pilot Initiation Initial Pilot Projects Capabilities Pilot Architecture Infrastructure, Tooling, Lifecycle, Governance Pilot Initial Solutions General Release Architecture, Infrastructure, Tooling, Lifecycle, Governance…. Deploy New Services Plan Time Go To Next Transition Stage…… Requirements Refine Infrastructure, Tools, Lifecycle, Governance… Define, Develop New Supporting Services Develop Deploy Release
  26. 26. BPM+SOA Transition - Customizing the Details <ul><li>The transition must be continuously customized at each stage to help: </li></ul><ul><li>Introduce specific new tools, processes, techniques for specific different kinds of activities, such as: </li></ul><ul><ul><li>Minor upgrades and small enhances </li></ul></ul><ul><ul><li>Customizing COTs </li></ul></ul><ul><ul><li>Managing outsourced development </li></ul></ul><ul><ul><li>Integrating legacy systems </li></ul></ul><ul><li>Integrate with and adapt to specific legacy processes, tools and organizational structures </li></ul><ul><li>Clearly define the roles, tasks, etc. for all stakeholders in activities at stage/phase of the transition </li></ul><ul><li>Directly involve the stakeholders themselves in the transitioning process. </li></ul>
  27. 27. MDS - Using MDA To Manage the Transition <ul><li>Apply MDA’s CIM-PIM-PSM pattern to the transition itself: </li></ul><ul><ul><li>Business Model (CIM) </li></ul></ul><ul><ul><ul><li>model business/IT ‘solutioning’ domain </li></ul></ul></ul><ul><ul><li>Solutions Model (PIM) </li></ul></ul><ul><ul><ul><li>adapt CIM to a model-driven process based on BPM+SOA </li></ul></ul></ul><ul><ul><li>Implementation Model (PSM) </li></ul></ul><ul><ul><ul><li>customize PIM to specific tools, techniques, project types, organizational structures </li></ul></ul></ul><ul><ul><li>Deployment </li></ul></ul><ul><ul><ul><li>plan and execute of each transitioning activity (we call these ‘engagements’) within each stage, phase, and track </li></ul></ul></ul><ul><li>Give all this a cool new name (and acronym!): </li></ul><ul><ul><li>Model Driven Solutioning (MDS)™ </li></ul></ul>
  28. 28. MDS - High Level Overview Detailed Engagement Models Business Models for ‘ Solutioning’ Transition Architect Process Designer Program Manager Engagement Activities ‘ Model-Driven Solutioning” Process Models Project Manager
  29. 29. MDS - Major Advantages <ul><li>Provides formal way to plan, manage, and customize the transition to BPM+SOA (or anything else!) </li></ul><ul><ul><li>Helps communicate both modeling and transition concepts </li></ul></ul><ul><ul><li>Involves all stakeholders in the transitioning process </li></ul></ul><ul><li>Supports iterative, ‘just-in-time’ approach for transition: </li></ul><ul><ul><li>Progressively change, enhance, and customize engagement models and transition deliverables during every stage/phase </li></ul></ul><ul><li>Can be used to help automate production of: </li></ul><ul><ul><li>Project plans and documentation </li></ul></ul><ul><ul><li>RFIs, RFPs, RFQs </li></ul></ul><ul><ul><li>Tooling configurations </li></ul></ul><ul><ul><li>Training materials </li></ul></ul><ul><ul><li>More… </li></ul></ul>
  30. 30. MDS – Recent Real-Life Example <ul><li>Proof-of-concept project for very large US integrated healthcare insurance provider </li></ul><ul><li>Focused on developing a single frame-of-reference for transitioning all stakeholders </li></ul><ul><li>Used to ‘sell’ BPM+SOA to both business and IT management </li></ul><ul><li>Based on careful observations of ‘real projects’ </li></ul><ul><li>Currently piloted in a ‘real’ IT production project </li></ul>
  31. 31. MDS Example - Model Fragment
  32. 32. Searching for the Holy Grail - Summary <ul><li>The Holy Grail sounds simple enough, but finding it is not. </li></ul><ul><li>BPM and SOA are promising approaches, but need conceptual ‘glue’ (like MDA) to work together </li></ul><ul><li>Transitioning large organizations to any new approach can be a difficult problem: </li></ul><ul><ul><li>Many different kinds of stakeholders and activities </li></ul></ul><ul><ul><li>Must be managed and governed </li></ul></ul><ul><ul><li>Ad hoc approaches don’t scale </li></ul></ul><ul><li>Fortunately, we can help … </li></ul>
  33. 33. Questions?