Adapting Model Driven Solutioning (MDS) to Customer Requirements

1. Adapting Model Driven Solutioning (MDS)to Customer Requirements Michael Guttman Montages Technology Partner CEO, The Voyant Group, LLC (USA)

2. Adapting MDS to Customer Requirements • Searching for the ‘Holy Grail’ • The Importance of ‘Solutioning’ • Model Driven Solutioning (MDS) • Early Applications of MDS • Recent Applications of MDS at Montages • Future Directions for MDS

3. The Holy Grail of Business • Business conditions change • Business correctly identifies new needs and opportunities • Business precisely specifies new solutions • Business efficiently acquires, implements and deploys those solutions • Business reaps associated rewards • Go to 1

4. The Holy Grail Sounds Simple Enough, But…. • The business does not describe its needs and opportunities in a consistent way • Different groups (e.g. Business Units and IT) speak very different ‘solutioning’ languages • Nobody follows efficient or consistent processes for creating, acquiring, integrating and customizing solutions • Solutioning projects are ‘balkanized’ into functional – and non-functional - silos • Existing silos and layers of legacy organizations, processes, software, hardware and ‘muddleware’ compound all of the above

5. Meanwhile…. • Spectacular project failures are becoming more common. • Frequent less spectacular failures, delays, and cost overruns are leading to increasing business dissatisfaction, especially with IT • Systems and data maintenance and integration activities dominate business and IT budgets and human resources; little bandwidth remains for new initiatives • Promising approaches like BPM and SOA are increasingly harder to integrate into legacy organizations, processes, and infrastructure • All the above results in increasing burnout and fatalism that undermine creativity, productivity and loyalty

6. Where Have We Gone Wrong? • Not for lack of trying – but with too many poorly-planned, uncoordinated initiatives • BPM, SOA, 6-Sigma, Agile, Outsourcing… • Focus on tools and technology, rather than process, organization and content • Increasing emphasis on cutting costs, rather than improving overall performance • Project-centric – rather than program-centric – planning, budgeting and governance • Lack of a truly ‘holistic’ and incremental approach that covers all solutioning activities

7. Does This ‘Solutioning Process’ Look Familiar? And at least this process is well-documented!

8. Can We Get Back To The Right Path? • Maybe – no guarantees • No one tool, process, software package, vendor or approach can provide everything • Legacy is ‘here to stay’ - no new approach can ignore existing systems, tools, processes or organization structures • To be successful, any new approach will need to adapt to the legacy environment, and then be further iteratively customizable over time as conditions change • Successfully adopting and adapting new approaches over time requires integrating them into an overall ‘solutioning process’ that is very flexible.

9. What is ‘Solutioning’? • ‘Solutioning’ is the overall process by which an enterprise creates and evolves solutions to perceived problems or opportunities. • ‘Solutioning’ includes (but is not limited to): • Problem identification • Problem analysis • Solution definition • Solution program/project organization and management • Solution acquisition, implementation and integration • Solution deployment, maintenance and evolution • Budgeting, funding, and administration of all the above

10. Why is ‘Solutioning’ So Important? • No matter what an enterprise thinks it does (e.g., ‘manufacture shoes’), ‘solutioning’ is what it really does! • That’s because an organization can only survive and prosper if its solutioning process is at least sufficient to respond to changing business conditions. • Organizations with the most effective and timely solutioning processes gain market advantage over time by responding better/faster to new opportunities/challenges. • Therefore, progressively improving the solutioning process can be ultimately more valuable than solving any particular business problems or improving any particular business processes.

11. Isn’t ‘Solutioning’ Just Another Form of ‘Business Process Management’ (BPM)? • Yes – and no… • ‘Solutioning’ is the overall process of identifying and solving problems’, as such, it is a key (maybe ‘the’ key) business process for managing all other business processes. • However, traditional BPM is focused on domain-specific business activities, e.g. “placing an order”. • Also, traditional BPM is usually not concerned with other parts of the solutioning process (e.g. implementation/maintenance of solutions). • Therefore, traditional BPM may be viewed as one possible tool/method within an overall solutioning approach. • However, as we shall see, BPM can be used to help model and improve the overall solutioning process itself ….

12. Why Model the Solutioning Process? • It is generally accepted that modeling traditional line-of-business processes (e.g. ‘order entry’) typically results in improved process performance and reduced costs • However, ‘solutioning’ is really the most fundamental process in any business, and ultimately impacts the performance of all line-of-business processes • Therefore, applying modeling to the ‘solutioning process’ first should yield the highest long-term ROI by improving the rate at which all other processes improve • This is even more true because the solutioning process at most enterprises is currently poorly understood and woefully inefficient

13. Modeling the Solutioning Process – An Example

14. What is ‘Model Driven Solutioning’ (MDS)? • MDS is an approach to continuously improve the overall solutioning process by progressively documenting and optimizing that process using formal modeling techniques. • MDS adapts to the existing solutioning process – it does not attempt to change it directly. MDS works even if – and especially if – most or all constituent parts of the solutioning process are sub-optimal. • MDS does not dictate any particular implementation of itself; that is, MDS can easily present itself to each solutioning participant using the solutioning approaches, tools, techniques, and processes most familiar to that participant.

15. MDS and Model Driven Architecture (MDA) • MDS is a specific application of Model Driven Architecture (MDA) to the problem of solutioning. It should not be confused with other applications of MDA (e.g. code generation from models). • MDS uses MDA-related modeling patterns to integrate otherwise disparate solutioning approaches, techniques and tools into an overall solutioning model. • Like MDA, MDS is modeling-language-agnostic – that is, almost any modeling approach, language, or tool can be integrated into MDS, and/or used to model MDS itself.

16. Solutioning Business Models Solutioning Architect Solutioning Design Models Solutioning Process Designer Solutioning Specification Models Solutioning Program Mgr. Solutioning Implementation and Deployment Solutioning Project Mgr. MDS - High Level, Top-Down, MDA-Style Viewpoint Computationally Independent Model (CIM) Platform Independent Model (PIM) Platform Specific Model (PSM)

17. MDS – Example – State of Wisconsin (1) • Improve IT RFP Process for State Welfare Agency • The problem: • Existing solutioning process dictated outsourcing of all IT projects • Typical outsourcing cycle was 3-5 years! • Resulting solutions were hard to maintain, evolve, or integrate. • Contributing factors • Requirements gathering process was slow and error-prone • Generating IT specifications was slow and error-prone • Generating RFP documents was slow and error-prone • Evaluating RFP responses was long and complicated • Business requirements changed frequently during RFP development and response analysis process, requiring massive rework

18. MDS – Example – State of Wisconsin (2) • The solutioning approach: • Develop high-level business model (CIM) of solutioning process; gain consensus from all major stakeholders. • Streamline the requirements gathering process by introducing business domain modeling tools and techniques to business analysts • Automatically generate all required RFP artifacts from business models • Require RFP respondents to indicate differences between their proposed solutions and elements of the RFP business models • The results: • Dramatic improvements in requirements gathering speed and quality • Requirements changes quickly accommodated up through RFP issue date • Mapping business requirements to IT specifications was standardized • Time/effort required to generate formal RFP documents totally eliminated • Overall RFP process reduced from 3 years to 3 months! • Resulting solutions are much easier to maintain, evolve and integrate

19. Solutioning Business Models Solutioning Architect Solutioning Design Models Solutioning Process Designer Solutioning Specification Models Solutioning Program Mgr. Solutioning Implementation and Deployment Solutioning Project Mgr. MDS – Example - State of Wisconsin (3) Model Overall Solutioning Process Introduce Business Modeling Specify RFP Auto-Generation

20. MDS – Montage Example – Large CH Bank (1) • Improve Documentation for Global Data Warehouse • The problem: • Difficult to track warehouse data supplied by regional systems back to relevant business decisions • Expensive, time-consuming, error-prone process to assess/predict the impact of regional system changes to warehouse data • Resulting errors could potentially cause serious problems in data quality, integrity, and availability to client applications • Contributing factors • Overall solutioning process did not include documentation change management • Scarce centralized resources tied up in document management and analysis for regional systems

21. MDS – Montage Example – Large CH Bank (2) • The solutioning approach: • Develop high-level business model (CIM) of required documentation process, integrated into overall solutioning process; gain consensus from all major stakeholders • Develop formal document repository model; implement repository • Reverse-engineer desired documentation metadata from existing artifacts • Develop forward-engineering documentation change management process; integrate into existing solutioning process. • The results: • Implementation artifacts now clearly tied back to relevant business decisions • Dramatic improvements in documentation availability and relevance • Documentation change management simplified • Change management responsibility can be distributed to regions, freeing scarce resources • Resulting solutioning models can be reused in other projects/programs

22. Solutioning Business Models Solutioning Architect Solutioning Design Models Solutioning Process Designer Solutioning Specification Models Solutioning Program Mgr. Solutioning Implementation and Deployment Solutioning Project Mgr. MDS – Montage Example – Large CH Bank (3) Model Overall Solutioning Process Integrate Document Mgmt into Solutioning Process Specify Document Mgmt. Repository Model and Process

23. MDS – Montage Example – UML Conceptual Model (1)

24. MDS – Montage Example – Current Excel View (2)

25. MDS – Montage Example – BPMN View (3)

26. MDS – Montage Example – Jaree – Small Start-Up (1) • Improve Marketing Performance Management (MPM) • The problem: • Many firms have no process to manage performance of their marketing activities; Jaree has developed a proprietary MPM process • In order to grow, Jaree needs to progressively automate its entire sales, marketing, and delivery process, ultimately productizing its offering • Automating piecemeal will take too long, cost too much, and leave Jaree with point solutions difficult to evolve and integrate; also, Jaree solutions must integrate easily with legacy systems/process of all future customers • Contributing factors • As a startup, Jaree’s business model is evolving rapidly, and it needs its solutioning process to adapt accordingly • Traditional approaches to business modeling and software development do not take into account Jaree’s unique solutioning needs as a startup • As a start-up, Jaree is resource-constrained in money, people, and time.

27. MDS – Montage Example – Jaree – Small Start-Up (2) • The solutioning approach: • Develop lightweight, agile approach to modeling and prototyping using off-the-shelf (OTS), open source (OS) tools and techniques • Develop high-level model of Jaree solutioning process and MPM domain • Prototype representative solutions to test models. • Progressively adapt models and prototypes to business evolution • Evolve prototypes into interim solutions as feasible; delay fixed implementation decisions as long as possible • The (early) results: • Improved understanding of solutioning model and MPM model leading to significant rethinking of Jaree business plan • New revenue opportunities have been uncovered and related dependencies identified • Original software implementation plan being radically restructured, resulting in the freeing of scarce resources freed for more strategic activities

28. Solutioning Business Models Solutioning Architect Solutioning Design Models Solutioning Process Designer Solutioning Specification Models Solutioning Program Mgr. Solutioning Implementation and Deployment Solutioning Project Mgr. MDS – Montage Example – Jaree – Small Start-Up (3) Model Overall Solutioning Process Integrate Model-Driven Rapid Prototyping Techniques Specify Model-Driven Software Development Processes

29. Adapting MDS – Some Conclusions • MDS can be introduced into any part of the solutioning process at any time; it is easy to introduce because it readily adapts itself to the ‘host environment’ – existing people, tools, processes - rather than demanding the host environment change to accommodate MDS • MDS ‘forces’ alignment, consistency, and accountability, but without compelling any particular changes in existing solutioning or business processes or practices • MDS delivers the most ‘bang for the buck’ of any modeling approach; introducing MDS first makes it much easier and more cost-effective to introduce other kinds of modeling in specific solutioning activities.

30. Questions?