Liiketoiminta-arkkitehtuuri CxO Academyn aamiaistilaisuus 15.5.2013 Tero Kulha Eeranka Oy
Kokonaisarkkitehtuuritutkimus 2012 Kattavuus Organisointi Liiketoiminta Tieto Järjestelmä Teknologia 0% 50% 100% Tietohallinto Kehitys- tai erillisyksikkö Muu Lähde: Suomalaisten organisaatioiden kehittämistoiminnassa on paljon parannettavaa. CxO 24.4.2012
Kokonaisarkkitehtuurin kattavuus Muu kuin tietohallinto (N=12) Liiketoiminta Osuus Tietohallinnolla (N=21) Liiketoiminta Osuus Tieto Tieto Järjestelmä Järjestelmä Teknologia Teknologia 0% 50% 100% 0% 50% 100% Lähde: Suomalaisten organisaatioiden kehittämistoiminnassa on paljon parannettavaa. CxO 24.4.2012
Liiketoiminnan ja tietohallinnon yhteistoiminnan esteet Prosessit kuuluvat liiketoiminta-arkkitehtuuriin Puutteet prosessien omistajuuksissa ovat Liiketoiminnan mielestä (N=15) pahin yhteistoiminnan este (60 %) - IT-terminologian on yhtä paha Tietohallinnon mielestä (N=55) toiseksi pahin este (73 %) - pahin koskee johtamiskulttuurin puutteita (75 %) Lähde: Johtamiskulttuurin puutteet tärkeimmät liiketoiminnan ja tietohallinnon yhteistoiminnan esteet. CxO 23.8.2012
Liiketoiminta-arkkitehtuuri CxO Academyn aamiaistilaisuus 15.5.2013 Tero Kulha Eeranka Oy
Standard EA Domains Process Architecture Information Architecture Application Architecture Technical Architecture 5/15/2013 6 Copyright Eeranka Oy 2011
EA = BA + EITA and part of strategy Copyright Eeranka Oy, 2013
Example from Nordic Company Copyright Eeranka Oy 2011 8
TOGAF s metamodel Source TOGAF 9.0 9
Most Popular Cloud Strategy Strategy Structures Process Info Apps Tech Copyright Eeranka Oy 2012
All stacks aligned Mission Visio Biz Strategy Organisation Processes and Quality Information Applications Infrastructure Source: Outotec
Combining strategy and structures Business Strategy (&Vision& Mission) Business Models Capabilities (derived from biz models) Business Services EA domains Process Info Apps Tech Copyright Eeranka Oy 2012
Defining Business Model Business model is a representation of how a company buys and sells goods and services and earns money. Alex Osterwalder Copyright Eeranka Oy, 2011
Original Canvas Copyright Eeranka Oy 2011 14
More detailed level 15
Defining Capabilities Wikipedia: Capability is the ability to perform actions. As it applies to human capital, capability is the sum of expertise and capacity. Osterwalder: A capability describes the ability to execute a repeatable pattern of actions. On organisation has to dispose a number of capabilities to be able to offer its value proposition. Capabilities are based on a set of resources from the organisation or its partner(s). Nordic FiCo: Capability is something an organisation is good at or wants to be good at. Capabilities describe the WHAT and processes describe the HOW. Annukka Oiva: Kyvykkyys on sekä aineettomien että aineettomien resurssien integroitumisprosessin tuloksen syntynyt yhteenliittymä, resurssien kimppu (bundle of resources). Kyvykkyys on kietoutunut organisaation infrastruktuuriin, erityisesti sisäisiin prosesseihin, ja se ilmenee organisaation vakiintuneina käytäntöinä. Copyright Eeranka Oy, 2011
Capability characteristics US Military Manual states that capabilities must satisfy two rules: Capability definitions must contain the required attributes with appropriate measures of effectiveness (e.g.: time, distance, effect [including scale] or obstacles to overcome). Capability definitions should be general and not influence a decision in favor of a particular means of implementation. The definition should be specific enough to evaluate alternative approaches to implement the capability. Copyright Eeranka Oy 2011 17
Service Hierarcy Higher level value chain or capabilities Business Service Service Contract* Service Qualities Business Process (lower level) Event Actor Business Entity *) Service level agreement between business partners Skill Information System Service Service Contract** Service Qualities Service Management Process **) Service level agreement between business & IT Event Actor Skill Metadata Entity Logical Data Component Logical Application Component Service Catalog Platform Service Service Contract*** Service Qualities Service Operation Process Event Actor Physical Data Component Physical Application Component Logical Technology Component - 18 - ***) Operating level agreement between IT functions Skill Physical Technology Component
Why Should We Do BA? 1. Implementing strategy Copyright Eeranka Oy, 2011
Risk of scattered requirements Business Strategy (&Vision& Mission) Current State Future State Business Models Gap Capabilities (derived from biz models) PROJ A PROJ B PROJ C Discrete requirements (Business Services) EA domains Process Info Apps Tech ICT PROJECTS AND OPERATIONS Copyright Eeranka Oy 2012
Why Should We Do BA? 1. Implementing strategy 2. Impact analysis (opened and closed options) <= needs a lot of understanding about the dependencies <= dependencies need to be done visible Copyright Eeranka Oy, 2011
Enterprise Business Motivation Model Business Business Unit Business Process Directive Industry Five forces Company Enterprise Success Metric Business Role Measures/ KPIs Business Policy Regulations Business Rules Assessment SWOT Recommendation Impact Business Model Finances Offerings Markets Alliances Channels Competencies Business Capability Arch. Risk Maturity Data Object Data Element Business Term Bus.Info Model Influencer Driver Initiative Application Business Trends Principles Proposed Change Requirements Competition Goals Roadmap Platforms Legislative Edict Strategies Outcome Components Source: Nick Malik, The Enterprise Business Motivation Model
Why Should We Do BA? 1. Implementing strategy 2. Impact analysis (opened and closed options) 3. Reducing complexity proactively: Where and what can we improve? Copyright Eeranka Oy, 2011
Where can we improve? With help of models one can demonstrate structures (and their complexity) pain points (e.g. process duplications and its implications) risks opportunies (in value chain /network) When you develop business one project at time it usually just increases complexity. Copyright Eeranka Oy, 2011
Why Should We Do BA? 1. Implementing strategy 2. Impact analysis (opened and closed options) 3. Reducing complexity proactively: Where and what can we improve? 4. Agility Copyright Eeranka Oy, 2011
Plug and Play modular architecture Fast changing markets Reconfigurable organizational units and business models Modular business infrastructure Process A Process B Process C New opportunities FIT Unit 1 Unit 2 Unit 3 FIT Processes Applications IT Agility cannot be based on chaos, but on modular and configurable structures. Combination of economics of scale and agility Source: Fast Strategy, Yves Doz & Mikko Kosonen
What do Business Architects do? Our work consist of Understanding strategic themes and drivers Modeling value chains, value streams, configurations Context modeling e.g. external interactions Capabilities, including business capability, service capability (including both business and IT capabilities), capability maturity, targets and gaps Calling out the interdependencies of all the business and architecture domains: strategy, governance, market, distribution, product, capability Design entities, people (organization structure, incentives), process, systems, functions, roles Linking with and supporting the strategy and injecting into the investment planning cycle Business Architects focus on WHAT, Solution and Technology Architects on HOW Source: http://blog.opengroup.org 27
Strategia ja kyvykkyydet Strategiassa määritellään, miten organisaatio hyödyntää kyvykkyyksiään (= kaikkea sitä mitä se osaa) menestyäkseen kilpailussa. Strategiassa otetaan kantaa myös siihen, mitä kyvykkyyksiä tarvitaan (ns. kyvykkyysaukko) ja miten niitä kehitetään. Lyhyellä tähtäimellä kyvykkyydet määräävät sen, millaiset strategiat ovat mahdollisia. Strategia implementoituu business-malleina, joissa hyödynnetään olemassa olevia kyvykkyyksiä ja ohjelmina joiden puitteissa kehitetään kyvykkyyksiä. Arkkitehtuurissa linjataan, miten kyvykkyydet organisoidaan mahdollisimman joustaviksi ja tehokkaiksi. Copyright Eeranka Oy, 2011
Ote artikkelin yhteenvedosta Liiketoiminta-arkkitehtuurissa on paljon potentiaalia modernina suunnittelumenetelmänä. Siihen liittyviä avainsanoja ovat systemaattisuus ja pitkäjänteisyys. Toiminnan keskeisenä tavoitteena on saavuttaa parempi ymmärrys organisaation toimintojen riippuvuuksista ja sen avulla toimintojen parempi kontrolloitavuus ja muokattavuus suhteessa muuttuvaan ympäristöön. Copyright Eeranka Oy, 2011
KIITOS & KYSYMYKSIÄ tero.kulha@eeranka.fi 040-506 88 86