User perspectiveFrom the perspective of the user organization, technology is usually acquired as the solution to some perceived problem or opportunity. This often follows a requirements engineering process, in which indeterminate wants are converted into defined needs, and a business case is constructed to support investment and/or procurement judgements.Procurement and implementation are often regarded as separate concerns. In the worst case, this may result in the procurement of solutions that turn out to be completely unimplementable. More frequently, attempted cost savings in the procurement process can result in significant cost escalations in the implementation process.Existing methods for requirements engineering, business case formulation and procurement are weak in methods for analysing implementability and for optimizing the total costs of acquisition and implementation. For a given solution, the main questions from the user perspective are as shown above:Users will want to compare several alternative solutions against these four criteria. They will also want to consider interactions between technologies, since they are unlikely to have the luxury of implementing technologies one at a time. Vendor perspectiveFrom the perspective of the vendor, technological products are usually developed to provide a solution to some class of perceived problems or opportunities, in some class of potential user organizations. This may follow a market requirements survey (demand pull), or may emerge from research and development (technology push).During the planning, development, marketing and selling of the solution, the vendor needs to think about the deliverability and implementability of the solution. Once the solution is developed and sold, the vendor may need to think about the actual method/approach of delivery and implementation. For a given type of user organization, main questions from a vendor perspective are:Vendors also wish to develop generic approaches, so that they can reuse tactics, materials and skills across many customers and prospects.
Capability Depth“These C2 maturity levels are scalable, in that they can be applied to groups of individuals and organizations of any size.”Source: Maturity Levels for NATO NEC Command, Dec 2006Capability Breadth“A scope based approach to maturity is the most useful determinant of maturity that decomposes well to each of the stream views because services are increasingly useful as they are used more widely, and conversely expanding the SOA scope beyond traditional organizational boundaries is without question the hardest thing to achieve “Source: CBDI Forum, Fine-Tuning the SOA Maturity Model, April 2007
OutcomesOutcome DistributionIn many situations, outcomes are not just simple binary events, but can be quantified. It is often useful to distribute outcomes across two dimensions – breadth and depth. Breadth refers to the scale, quantity and diversity of the outcome. For example, the penetration of a given technology across a target user population. Given an assumption of heterogeneity across the target population, greater breadth typically requires some degree of differentiation. Depth refers to the quality and intensity of the outcome. For example, the ability of some sectors within the target population to achieve maximum exploitation of a given technology. Given an assumption of complexity in the systems architectures, greater depth typically requires some degree of integration (which may be physical or virtual),
Building a Roadmap forImplementingSocioTechnical ChangeNotes on Accommodation,Assimilation and Maturity Richard Veryard September 2012
Implementing something somewhereSomething … Somewhere …Suppose we wish to implement … into some system or A technology environment A product or platform An organization, which may be distributed or federated A solution (to some problem or requirement) An ecosystem A strategy or policy A community, which may be homogeneous or A complex change heterogeneous A concept (e.g. “excellence”, “org intelligence”) Let’s call this “the target”.Let’s call this “the solution”
Implementation requires AdaptationAccommodation Assimilation The target must The solution must be accommodate the assimilated into the solution. target. Therefore there must be Therefore there must be some managed change to some managed change to the solution. the target. E.g. detailed solution E.g. organizational development or development customization
AssimilationSolution as built Solution in useDevices, support systems (vendor Local instructions & guidelines,hotline), general interfaces, local interfaces, workingtraining packages, standard practices, fixes and work-(reusable) solution templates arounds, user templates, usability gap
Implementation Endpoint: MaturityA mature solution … … in a mature target Solution as Organization Designed aligned Intentions aligned aligned Solution aligned Organization in Use Reality
So this gives us five streams of managedadaptation/adoption Direction and Coordination Solution as designed/built maturity Solution in use Organizational realities Organizational intentions time
Each stream can be managed separately Different management concerns Different specialist skills (technical, organizational, political, cultural) Different timescales, characteristic rates of change
Multiple Time HorizonsHours Install softwareDays Train staffMonths Pilot project, Renegotiate incentives Budget cycleYears Technological maturity Cultural changeDecades Technological lifecycles Deep cultural change
Management Hierarchy months years decades days months years decades hours days months years hours days months hours days
Two PerspectivesTarget Management Perspective Supplier Perspective Can we implement this Can we deliver this solution? solution? How should we How should we deliver implement this solution? this solution? How much will it cost How much will it cost us? overall? How much will it cost the How long will it take? customer overall? How long will it take?
Implementation Roadmap implies a Maturity Model SOA example NCW example Command and Control Self- Traditional Collaboratio Synchronizatio n n Shared Awareness 3 4BusinessConsistency& Design Developing Information Situational Sharing Time to Market Awareness 1 2 Cost Reduction Risk Reduction Organic Sources 0 Source CBDi Source: CCRP
Capability Levels Readiness Maturity Null No relevant capability identified Learning Excellent Some relevant initiative or trial identified Adequate Improving Sufficient to get started Improving Getting more efficient and/or effective Learning Adequate ExcellentNull Enabling maximum performance.Must Should Could Source: CBDI Forum
Two Dimensions of Capability Maturity<<C2 Maturity Level>>Agile Enterprise<<C2 Maturity Level>>Agile<<C2 Maturity Level>>Collaborative<<C2 Maturity Level>>Coordinated<<C2 Maturity Level>>Deconflicted<<C2 Maturity Level>>Conflicted 15 <<Scope>> <<Scope>> <<Scope>> <<Scope>> <<Scope>> Fragment Process Domain Enterprise Ecosystem
Outcome Distribution DifferentiationIntense usage by selected Deep Full users Usage Usage Integration Initial Broad Usage Usage Occasional Outcomes usage by many users
Capability Stepping stone Phasing capabilitiesSet of capabilities needed tosupport proper usage by selectedusers DifferentiationFocus on integration Deep Full(=joining things up) Set of capabilities needed Integration Initial Broad(Deep Usage = Applied) Outcomes to broaden the user base across the extended enterprise Focus on differentiation (=supporting diversity ofSet of capabilities needed to get started usage across different(Initial Usage = Early Learning) classes of user) (Broad Usage = Enterprise)
Capability Dependency Quantity of UsagePhase 2 Citizen-Centric Integration Diversity of Applications Value of Usage (“Joined-Up18 Experience”) Understanding Citizen Process Integration of PortalSemantics Supply-Side Integration Outcomes Integration Outcomes Knowledge about usage Technical Rich Integration Content (WSRP?) User Differentiated Popular Textual Awareness Feedback Support Content Solution Support for Loop (“user-friendly”) Funding Special Stakeholder Groups User Support (Help Desk) Communication “My Page” Customization programme Profiles Additional (Marketing) Solutions Funding Stakeholder Broad range Strategy Citizen Identity and Identification of content AuthenticationPhase 1 Phase 3
Phasing and Milestones (SOA Example)Adoption Fragment Project Domain Enterprise EcosystemPhases Committed Committed Status Interested (Domain) (Enterprise) Expertise Isolated Shareable Widespread Assets Low Medium High Activities Volume Volume Volume Standard Provisional Adopted Optimized Practices Few Minority Minority Majority Projects Pilot Stand-Alone Integrated Integrated
Evolutionary AdaptationThe Solution Changes Over Time The Taregt Changes Over Time Evolution of Learning by doing requirements - what we Ongoing interaction with really want countless other change Demanding solutions – programmes and what the solution requires initiatives from us
Moving the GoalPostsMaturity as Sociotechnical CongruenceSocio … … technical Actual Technology Organization in Use Envisioned Installed Organization Technology
Balancing the Elements of Implementationbased on ancient Chinese thought Fire represents drive or purpose The Implementation Program Fire champions the benefits of the solution Earth represents the raw material, networking, social infrastructure. The Program Office acts as a Center ofWood Earth Excellence Metal represents formal structure Custodian of architectures and processes Water represents intelligence, insight Identifying and promoting opportunities for sharing, collaboration and synergy. Water Metal Wood represents planned activity A Program Office to performs programme management and coordination functions.
… based on ancient Chinese thought which leads to a cycle of workshops Benefits Agree business case Motivation Support Agree the transition organization, including Project(s), Program Office and Steering Committee. Provision tools andDelivery Support infrastructure.Growth Network Structure Adopt and customize formal structures (Reference Architecture, Process) Understanding Opportunity Architecture and planning Delivery Understanding Formal Opportunity Structure Benefits Review ROI from implementation activity, approve next iteration
History This framework was first developed in the late 1980s for implementing software development tools and methods (Information Engineering and associated CASE tools) into large organizations. The framework has also been used for subsequent technologies including SOA. The theoretical framework has been presented at a number of conferences including IFIP WG 8.6 (1994).