Value-oriented Enterprise Engineering Uncovering the rationale behind organization components João Pombinho, David Aveiro and José Tribolet EEWC 2013 Luxembourg, May 2013 Agenda Introduction and Motivation Problem Statement – Where is the Value? Related Work – e3value and DEMO Research Approach Proposed Solution Value-oriented Solution Development Process Solution Development Organization Practical Case Conclusions “Why do so many IT leaders do such a terrible job of running their departments like a business? Because they put too much emphasis on supply and not enough on demand.” 1 Doing things right vs ... do we really have to choose? doing the right things 1 Michael Gentle, “A New Model for IT Demand Management”, cio.com, october2007 Introduction and Motivation The question is doing things right vs doing the right things Ideally both! Let us consider two different perspectives of a system  Teleological, concerning its function and behaviour, a black-box Ontological, about its construction and operation, a white-box ICT-related approaches mainly deal with the ontological perspective… Yet, from the customers viewpoint, the organization does not matter!© Strategic failure is commonly attributed to Business/IT misalignment  Do systems and their supporting systems really belong to separate worlds? How to integrate Business and supporting System development?  Dietz, J.L.G., ed. Architecture - Building strategy into design. Academic Service, ed. N.A. Forum. 2008, Sdu Uitgevers.  Ross and Weil, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. 2006, HBS Press Problem Statement Remote Internet support Example In the case there is a perceived malfunction by the customer, she can contact the call center to identify and solve the issue. After calling the support number, her call is handled by an Interactive Voice Response (IVR) system. IVR allows customers to interact with the company via telephone keypad or by speech, so they can service their own inquiries by following the predefined process or eventually get redirected to a human operator. The client identifies herself by dialing the national ID number. Additional identification information can be requested for cross-check later in the call if there are relevant actions to be taken. Following, a diagnosis process is carried on. The diagnosis can be at customer side (e.g. check the modem lights) or at the provider side (e.g. check service provisioning status). After a diagnosis is established, a solution is attempted. Again, the solution can be at the customer side (e.g. reset device) or at the provider side (e.g. force firmware update). The call ends after reaching a solution or, if it is not successful, by requesting field service. Problem Statement Remote Internet support Example – Actor Transaction Diagram (ATD) REMOTE INTERNET SUPPORT ORGANIZATION CA01 A01 T01 solve problem A03 T03 T02 diagnosis specifier specify diagnosis identify customer A05 support requester T04 observe customer side symptoms problem solver T05 observe provider side symptoms provider side symptom observer A07 T06 T07 apply customer side solution apply provider side solution provider side solution applier CA02 T08 execute field service field service executor Problem Statement Remote Internet support Example – Rationale? Does a customer want to take part on diagnosis and solution application? Or she accepts it as a condition to be eligible for “free” support? Is it still justifiable if the customer pays for the service? Does the customer want to go through this process or is willing to pay for 2h SLA service restore? SMB? Is there a market, black-box, solution for this problem? If any hidden assumptions change, how should the organization adjust? REMOTE INTERNET SUPPORT ORGANIZATION CA01 A01 T01 solve problem A03 T03 T02 diagnosis specifier specify diagnosis identify customer A05 support requester T04 problem solver T05 observe customer side symptoms observe provider side symptoms T06 T07 apply customer side solution apply provider side solution provider side symptom observer A07 provider side solution applier CA02 T08 field service executor execute field service How does our model support the transformation of the organization to, say, improve customer support value through internal cost reduction? Problem Statement Main issues Traceability The construction of an organization obscures the system/subsystem relations and their motivation How is value dispersed by organizational components? Value/Function/Construction relations are not one-way: If restrictions cease to be, contextualized revision should occur What extra value can be generated by changing the construction? Function and, in turn, purpose, could be improved and/or extended, by improved implementation technology, better construction or both How to analyze cost reduction solutions, e.g. increase IVR automation? Problem Statement Summary While changing an enterprise one needs to be aware of value conditions imposed by stakeholders (past, present and future) Sometimes it is obvious by observing organization components, sometimes not Value conditions show how each part of an organization contributes to the purpose of the organization itself and of other elements in the organization's environment (market) Current research approaches do not model value in a formal way that can be related to the composition of the value providing system How to integrate the teleological and ontological perspectives of an enterprise model to support systematic value based system development decisions? Approach Methodolody - Design Science Research Context: real-world industry scenario - IT Demand Management practice at a Telco  ICT-enabled Enterprise Transformation Explicitating Value-based rationale GST DEMO e3Value Service Science GORE BMC Design Science Research cycles according to Hevner  e3Value and DEMO integration ontology VoSDP Organization VoSDP Method  Pombinho, Aveiro and Tribolet, The role of IT Demand Management on Business/IT Alignment: the case of ZON Multimedia, PRET 2013 (forthcoming)  Hevner, A.R., A Three Cycle View of Design Science Research. Scandinavian Journal of Information Systems, 2007. 19(2): p. 87-92. Approach Mindset Speaking the same language “Value is the most relevant negotiation common ground between business and IT””  Having a common referential Value orientation over the full lifecycle Promoting Alignment Coherency between models  Cameron, B., S. Leaver, and B. Worthington, Value-Based Communication Boosts Business' Perception Of IT. 2009, Forrester Research Related Work DEMO Why DEMO? Complexity reduction, retaining relevance Distinguishing intention, content and form Transactional pattern based on communication theory Formal definitions of competence, authority, responsibility Method – repeatability and consistency How to: 1) Improve problem specification? 2) Relate it with the construction? Related Work e3Value Ontological approach for modelling networked value constellations Introduces value model deconstruction and reconstruction  Directed towards e-commerce Creation, exchange and consumption of economically valuable objects No construction support Still, no structural support for a formal, content-based rationale for decisions Actors must be economically independent entities - constraint  Gordijn, J., Value-based requirements Engineering: Exploring innovatie e-commerce ideas. 2002, Vrije Universiteit Amsterdam: Amsterdam. Solution Proposal Overview and Developed Artifacts 1. e3Value and DEMO integration ontology 2. VoSDP Method 3. Solution Development Organization (SDO) SOLUTION DEVELOPMENT ORGANIZATION CA01 A04 A01 T03 T01 A03 specify solution list provide solution T04 A05 T05 solution requester result specifier specify result solution manager value designer T02 specify OS value model specify US value model solution development manager T009 T06 A06 functional designer specify OS functional model A10 select solution T010 implementer implement solution A07 T07 specify OS constructional model A11 T11 T08 value manager manage runtime value model specify OS implementation model constructional designer A08 engineer Solution Proposal - Ontology e3Value and DEMO integration Ontology e3Value: value coherence and completeness through assigning responsibility economic reciprocity value object enforcement on p-facts DEMO complexity reduction transactional context construction support Solution Proposal - Ontology Integration Ontology :: Aligning Actors + Value Transaction Actors are active elements of social systems and value networks, i.e., belong to a system part In DEMO, an actor is a subject fulfilling an actor role in a transaction type. The initiator and executor actor roles are related by their common interest in bringing about a production result In e3Value, both actors (provider and requester) are bound by the willingness to share value objects with the concept of reciprocity Artificial economical independence - actor role + subject match economic actor Actors connect by associating Value Ports of different directions A DEMO Transaction matches a Value Exchange, relating two value ports A Value Transaction involves at least two, according to the principle of economic reciprocity In the Library, Readers (US) choose to use the CSO (OS) to get a Book in exchange for Money LIBRARY CA01 CA00 T01 Customer Loan Book T02 Payment Library Kernel Solution Proposal - Ontology Integration Ontology :: Demand / Offer definition A Value Interface represents willingness to provide service to its environment An outbound Value Port specifies the offer of a particular Value Object To enter into transactions, actors must be competent to perform the associated acts: hasInValuePort x => x is competent to perform request and accept (c-act) hasOutValuePort x => x is competent to perform promise and state (c-act) hasOutValuePort x => x is competent to perform execute (p-act) A p-fact is produced by performing a Value Activity A value activity must be assigned to some actor; an actor has at least one value activity In e3Value, a given value activity is performed by precisely one elementary actor In the same way, a given transaction is executed by precisely one actor role in DEMO LIBRARY CA01 CA00 T01 Customer Loan Book T02 Payment Library Kernel Solution Proposal - Ontology Remote Internet support Example – Value model driven by construction Solution Proposal - Method Value-oriented Solution Development Process (VoSDP) Solution Proposal - SDO Solution Development Organization ATD SOLUTION DEVELOPMENT ORGANIZATION CA01 A04 A01 T03 T01 A03 specify solution list provide solution T04 specify result solution manager A05 T05 solution requester result specifier value designer T02 specify OS value model specify US value model solution development manager T009 T06 A06 functional designer specify OS functional model A10 select solution T010 implementer implement solution A07 T07 specify OS constructional model A11 T11 T08 value manager manage runtime value model specify OS implementation model constructional designer A08 engineer SOLUTION DEVELOPMENT ORGANIZATION CA01 A04 A01 T03 T01 VoSDP – Instantiation provide solution T04 result specifier specify result solution manager A05 T05 solution requester value designer T02 specify OS value model specify US value model solution development manager T009 I. Establish Problem A03 specify solution list A06 functional designer T06 specify OS functional model A10 select solution T010 implementer implement solution A07 T07 constructional designer specify OS constructional model A11 T11 T08 value manager manage runtime value model specify OS implementation model Following up on board decision, Head of Customer Support requests cost reduction by 20% What is the as-is value model? What is the overall value model it must comply to? The transactional costs are mostly due to the time human agents spend in: 1. 2. initial call handling, i.e., identifying the customer filtering away exceptions to normal diagnosis A08 engineer SOLUTION DEVELOPMENT ORGANIZATION CA01 A04 A01 T03 T01 VoSDP – Instantiation provide solution result specifier solution manager A05 value designer T02 specify OS value model specify US value model solution development manager II. Define Solution scenarios A06 functional designer T06 specify OS functional model A10 select solution T010 implementer implement solution A07 T07 constructional designer specify OS constructional model A11 T11 T08 value manager manage runtime value model specify OS implementation model A08 engineer Two (L2) SDPs are started by the solution development manager (L1) with the request of reducing human operator time by each of the conditions mentioned previously ORGANIZATION A CA01 condition #1 can be solved by using existing CRM services to identify a customer by DMTF keyed-in data CA02 T01 T08 provide solution execute field service T02 T12 identify customer identify customer T04 CUSTOMER IDENTIFIER ORGANIZATION condition #1 field service executor SUPPORT CONTEXT IDENTIFIER ORGANIZATION condition #2 support requester T13 observe customer side symptoms GSDP T04 specify result T05 solution requester T009 A03 specify solution list US (N-1) identify support context à OS (N-1) US (N) à OS (N) condition #2 can be solved by using existing services that, based on the customer address and portfolio, identify scope exceptions By splitting the initiating actor of the transaction, it is now possible to allocate different subjects that can execute more efficiently SOLUTION DEVELOPMENT ORGANIZATION CA01 A04 A01 T03 T01 VoSDP – Instantiation provide solution In order to rationally select solutions scenarios, objective criteria must be defined Using e3Value it is possible to assign valuation formulas to value object transferences through value ports e3Value also defines the concept of expenses which contribute to the economic viability analysis but are not explicitly modeled as value exchanges: T04 result specifier specify result solution manager A05 T05 solution requester value designer T02 specify OS value model specify US value model solution development manager T009 III. Select Solution Scenario A03 specify solution list T06 A06 functional designer specify OS functional model A10 select solution T010 implementer implement solution A07 T07 specify OS constructional model A11 T11 T08 value manager manage runtime value model specify OS implementation model constructional designer A08 engineer Profitability sheet for scenario A Profitability sheet for scenario B Variable expenses (OPEX dep. on volume) Fixed expenses (OPEX per time period) Investments (CAPEX) e3Value allows specifying value model components using specific attributes that make the profitability sheets directly derivable from the model Assumptions: Stable customer revenue 900K customers have internet services and call 1,2 times/year on average for internet support reasons implementation of the new actors has a CAPEX of 30 K€ and OPEX of 2,4 K€ # calls handled by problem solver reduces by 15% avg support call duration lowers from 10 to 8 minutes because of effectively reduced support scope due to early context clarification SOLUTION DEVELOPMENT ORGANIZATION CA01 A04 A01 T03 T01 VoSDP – Instantiation provide solution solution manager A05 specify OS value model specify US value model solution development manager T010 implementer implement solution A06 functional designer A07 T07 specify OS constructional model A11 T11 T08 value manager manage runtime value model specify OS implementation model Use logged VoSDP information to improve T06 A10 select solution value designer specify OS functional model Check the created value conditions for gaps Trigger the Solution Development Process if necessary result specifier T02 T04 specify result T05 solution requester T009 IV+V. Implement and Evaluate A03 specify solution list constructional designer A08 engineer Using the developed IVR-based solution as a channel for up selling/cross-selling? … repositioning the CC organization from a cost center to a value center The opportunity of having the customer in-line can be taken advantage of by creating a discounted offer for these situations to be presented automatically (relatively inexpensive) and/or redirect the call to a sales operator (more costly; more effective?) Again, to explore this path, a new GSDP cycle is in sight! Application in Practice Business/Business alignment Business/IT Alignment? Value Model Project A EA Model Project A Global Value Model Global EA Model Application in Practice IT DM Process 2.0 – Value-oriented Project Request • Benefits • Value Model • Requirements Quickscan • Business Case • Integrated Value Model • IT Estimate Detailed Solution • Functional Units • Architecture • Both valuealigned DEVELOPMENT Planning • Priority • Dependencies • Value rationale Implementation and Delivery • Coding • Testing Runtime • PIR • Validate Value Model RUNTIME Application in Practice Challenges and preliminary Results Challenges The detail level attained by recursive application of the GSDP is quite high Forces the definition of value at design time No silver bullet: domain-specific design and construction principles are necessary Input - improved problem elicitation Decision - Business Case clarity GO/NOGO and prioritization Content - better input to Functional Analysis and following activities Stakeholders, scoping and value proposal Tracing BC benefits to implementation support Validation - Value Proposal at Post-Implementation Review Contributions & conclusion Ontology for integrating e3Value and DEMO Method – explicitating internal Value Chains Differentiating Construction, Function, Value and Purpose Integrating the Teleological and Ontological perspectives VM: value coherence, economic reciprocity, value object enforcement on p-facts EE: transactional context, construction support Addressing purpose recursively – use e3Value from a teleological perspective VoSDP organization specification Towards formalizing solution development process & rationale EE and Value Modeling are compatible and complementary à Contribute to formally increasing business and IT alignment Questions? Thank You! [email protected] linkedin/jpombinho - Support Slides - Generic System Development Process Overview Solution Proposal Contribution Perspective aspirant member annual fee controller member loan creator loan terminator source aspirant member board registrar annual fee controller member stock controller library publisher Construction author registrar loan creator library loan terminator Function Alignment internet researcher so ur ce casual reader gifter book c opy loa n bo ok co py library gift bookstore Contribution Related Work Analysis Archimate, Business Modeling and Requirements Engineering Archimate’s business layer relates to all three B-I-D layers of DEMO, without clear distinction Business Modeling approach (BMC) Application and technology layers are implementation-level Value - measure of appreciation of Business Service by Business Actor Value concept is subordinate to the Business Service Limits exploring multiplicity between Value and Business Service No value chain structure, i.e., relation between value nodes Uses concepts found/accepted on the business stakeholders UoD Semi-formal ontology that can be translated with other concepts Does not model constructional perspective GORE provide structure and traceability but no model the origin of the goals, their why dimension, in a structured way Representing motivation ≠ Business Engineering Solution Proposal - Ontology DEMO Ontology Summary Act - An atomic activity performed by an actor, resulting in the creation of a factum. Two kinds of acts are distinguished: coordination acts and production acts Actor - is a subject in fulfilling an Actor Role Actor Role - Unit of authority, responsibility and competence Competence - The ability of a subject to perform a particular type of production act and the corresponding coordination acts, i.e., the ability to be the executor of a transaction type Fact – An elementary state of affairs in a world Production Act - The act in a transaction by which the executor creates the production factum; Production Fact - An elementary state of affairs in the production world Transaction – A sequence of acts that is a path through the complete transaction pattern, minimally comprising the basic pattern; World - The concept of World is crucial to distinguish separate sets of System. System would not be enough to provide this distinction since there can be many interacting systems is a particular World. It represents the modeling UoD. Solution Proposal - Ontology e3Value Ontology Summary Market Segment – Groups value interfaces of actors which equally value objects Actor - An actor is perceived by his/her environment as an economically independent entity. It can be an Elementary Actor or a Composite Actor Value Object - Actors exchange value objects. A value object is a service (SD-Logic) which is of economic value for at least one of the actors involved in a value model Value Port - It belongs to an actor, and allows it to request value objects to the others actors. It is characterized by its direction (“in” or “out”); in the implementation Value Exchange - A value exchange is used to connect two value ports. It represents one or more potential trades of value object instances between value ports. Value Offering - A value offering models what an actor offers to, or requests from, his environment. An offering is a set of equally directed value ports exchanging value objects Value Interface - It belongs to an actor, and usually groups one “ingoing” value port, and one “outgoing” value port Value Transaction – A group of Value Exchanges that should occur simultaneously. It is interesting in modeling alternative scenarios, since different Value Transactions can happen as variations of a single Value Interface from one Actor’s perspective and towards different Actors. Introduction and Motivation What does IT Demand Management do? Consolidate business needs Identify and specify solutions Evaluate priorities and cost/benefit Plan according to delivery capacity Hands over to Delivery ... or not! Introduction and Motivation Practical Background IT Demand Management @ ZON Multimedia Portugal’s largest Cable Operator (TV, NET, Voice and Mobile) 30 business areas - Heterogeneous problem/opportunity descriptions The platforms (BSS) include: IT Demand Management Customer 1. DESIGN Architect 2. DELIVER User Functional Analyst Project Manager DEV 3. OPERATE Operation and Support Business IST Customer Relationship Mgmt(CRM) Enterprise Application Integration (EAI) Billing Enterprise Resource Planning (ERP) Field-Force Portals Comissioning Mediation Provisioning IT Department 1200+ new project requests / year + 400 backlog; >1/day/person No tool support, “no time” to model… decisions must be made! Introduction and Motivation Practical Background – Main activities and Value driver Specify Problem Quickscan/ GO/NOGO Specify Detailed Solution Plan Deliver Evaluate (PIR) Problem – clearly establishing the problem to be addressed and collecting additional information about it in order to link individual problem parts to purpose and value Specify Quickscan + Business Case Approval - developing solution scenarios. Can change scope or even solve problem without the need of IT project Detailed Solution –specification of FUs and validation of QS assumptions Prioritization and Planning - establishing a relative priority over all the active projects and planning with the Delivery area vs. capacity Post-Implementation Review (PIR) - after the delivery of the project, assist in verifying if the proposed value is effectively transferred by using the solution Introduction and Motivation IT Demand Management process Project Request Quickscan • Benefits • Requirements • Business Case • IT Estimate • Bottom-up Costs Detailed Solution • Functional Units • Architecture Planning • Priority • Dependencies Implementation and Delivery • Coding • Testing Runtime • PIR ! ! What is the value generated by a particular IT asset at runtime?