Adapting Model Driven Solutioning (MDS) to Customer Requirements

Portions copyright The Voyant Group 2006-7

Adapting Model Driven Solutioning (MDS)to Customer Requirements

Michael GuttmanMichael GuttmanMontages Technology PartnerMontages Technology PartnerCEO, The Voyant Group, LLC (USA)CEO, The Voyant Group, LLC (USA)


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


The Holy Grail of Business

1. Business conditions change

2. Business correctly identifies new needs and opportunities

3. Business precisely specifies new solutions

4. Business efficiently acquires, implements and deploys those solutions

5. Business reaps associated rewards

6. Go to 1


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


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


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


Does This ‘Solutioning Process’ Look Familiar?

And at least this process is well-documented!


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.


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


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.


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 ….


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


Modeling the Solutioning Process – An Example


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.


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.


MDS - High Level, Top-Down, MDA-Style Viewpoint

Solutioning Architect

Solutioning Process Designer

Solutioning Program Mgr.

SolutioningSpecification

Models

SolutioningImplementation

and Deployment

Solutioning BusinessModels

SolutioningDesign Models

Solutioning Project Mgr.

Computationally Independent Model (CIM)

Platform Independent Model (PIM)

Platform Specific Model (PSM)


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


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


MDS – Example - State of Wisconsin (3)





Models


and Deployment




Model Overall Solutioning Process

Introduce Business Modeling

Specify RFP Auto-Generation


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



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







Models


and Deployment





Integrate Document Mgmt into Solutioning Process

Specify Document Mgmt.Repository Model and Process


MDS – Montage Example – UML Conceptual Model (1)


MDS – Montage Example – Current Excel View (2)


MDS – Montage Example – BPMN View (3)


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.



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







Models


and Deployment





Integrate Model-Driven Rapid Prototyping Techniques

Specify Model-DrivenSoftware Development Processes


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.


Questions?

Adapting Model Driven Solutioning (MDS) to Customer Requirements

Documents

Transcript of Adapting Model Driven Solutioning (MDS) to Customer Requirements