Presentation on theme: "Enterprise architecture Being succesful as an architect TopTech, 22-04-2010 Rene van den Assem."— Presentation transcript:
Enterprise architecture Being succesful as an architect TopTech, 22-04-2010 Rene van den Assem
www.vka.nl2 Meet… VKA Verdonck, Klooster en Associates Independent consultancy Strategic projects with ICT
www.vka.nl3 Meet… VKA Since 1985 €17,2 million in 2008 120 people small 95% of customers come back repeatedly
4 Contents Enterprise Architecture What is it? Frameworks Principles, models Architecture, the process Blueprint versus development plan Steering with achitecture Do’s and don’ts Competences of the architect
5 Why enterprise architecture ? IT view Strategic Business – IT alignment Shared vision Communication Sceptic’s view Something IT think they need to let the IT department do the right things for the company.
www.vka.nl6 Why architecture? Solve issues for more than one project (reuse) efficiency, time-to-market, quality, cohesion Standardization complexity and cost reduction, improves control Discussie ad hoc Wensen lijnmanagers Wensen productmanagers Wensen CTO Aannames projectmanagers Slows projects down Results vary per project project… Discussion ad hoc Requirements Business managers Requirements Product managers Requirements CTO Assumptions projectmanagers …
7 What is (enterprise) architecture? We're not sure, but we know one when we see one. Seriously, it is a difficult concept to make precise. Perhaps this is not too surprising, given that the civil architecture community, with 5000 years or so of practice, has had little more success defining the architecture of a building.
www.vka.nl8 Views of enterprise architecture ANSI / IEEE1471 - 2000 Style – form – function Arche = begin, first, principle or norm Techne / tecton = technique, art of creating / building “Architecture is a process” Architecture is an experience
9 A definition ANSI / IEEE1471 - 2000 Architecture: the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. IEEE1471 is wijdverbreid en herkenbaar voor velen (vooral ICT’ers), maar niet de enige kijk op …
10 Mission System Architecture Environment Architectural description Architectural description Rationale Stakeholder View Concern Library viewpoint Library viewpoint Model fulfills 1..* inhabits influences has an has 1..* is important to 1..* identifies 1..* provides Is addressed to 1..* has source 0..1 organized by 1..* selects 1..* aggregates 1..* participates in participates in 1..* consists of 1..* used to cover 1..* conforms to establishes methods for 1..* described by 1 IEEE 1471-2000 Conceptual framework Viewpoint
11 Viewpoints en Modaliteiten: Zachman Enterprise Architecture
12 Nederlandse Overheids Referentie Architectuur Modalities (who, what, how) and aspects Mainly principles + some models, gov building blocks Reference architecture for entire NL government Start of several other government architectures Gemma, MARIJ
14 Generating Implementations Platform- Independent Model CORBA Model MDA Tool generates all or most of the implementation code for deployment technology selected by the developer. Java/EJB Model CORBA XML/SOAP Model Java/EJB XML/SOAP Other Other Model Map PSM to application interfaces, code, GUI descriptors, SQL queries, etc.
15 Structure of the architecture Viewpoints, separation of concerns: - MDA, Kruchten, Zachman, IAF Layering, one layer delivering services to the higher - GEM, ArchiMate Modalities, actor –who--, product/service –what--, process –how--, etc: - Zachman, NORA, Archimate Aspects, eg. security, management, etc.: - NORA
What is the real problem ? The right projects, done right Make IT add value Cost control Better control of IT Help a specific business change Business IT alignment Avoid silos and duplication
18 Artist impression versus ‘under the hood’ Artist impression Managers, general public Under the hood Architects Process and IT designers
Why use principles? Goal situation not completely clear Too much work Too many uncertainties But you can define the directions, important choices and values Make all members of organization act similarly. Same directional statements, same sense of priorities 19
Principles, format Format Name Statement Rationale Implications Optional: Relation to external sources (strategy & policy documents) Relation to other principles 20
www.vka.nl21 Principles: Business, Information / Application, Technology ACME promotes a high degree of ‘smooth execution’ of her services to the public. Applications are structures according to a four tier model: presentation, application, business logic and storage Servers are virtualized
23 Linking goals and principles Survey customers Communicate, compensate Changes Sales Organization incl 3rd parties Less / Other work to do Present incentive system Sales Possible loss of competent sales Implementation view Business view Research db products Technical view Compatibility, integration issues Need to develop or outsource Customer must check inventory, make valid orders Use scripts, database to check inventory and validity Customers browse, check inventory, order, pay without help Needed for e-commerce Requires 24 X 7 system availability No resources for 24X7 support Functional view Investigate partners Driver: Competition is outstripping us on delivery Goal: Improve time-to- market Develop e-commerce capability Reduces order processing time Needs modifications to IT infrastructure Beyond year’s budget
How to do principles ? Under the hood Attempt completeness 100+ Exact statements Direction, boundary conditions, construction Artist impression Only the essential 10-20 max Catchy phrasing Focus on direction, behaviour, mostly business principles www.vka.nl24
www.vka.nl28 Properties of models A purpose Viewpoint Scope Focus / view Modelling principles and conventions E.g. Groeping criteria “Things should be made as simple as possible, but not any simpler.” Einstein, Albert Einstein, Albert
32 Question:When is your drawing finished? A.When your customer snatches it from your hands (and walks away with a ) B.When your colleague architects have no more remarks C.When everything has been modelled correctly according to the method D.Never
Relation with ICT governance Business Strategy Information strategy IT-projects Cohesion Steering, control Architecture management Information planning IT “Going Concern” IT-service management IT-portfolio management
34 Bridging the gap between strategy and projects Strategic Business & IM Vision Transformation Plan Project Level Design Projects (Design / Development) Enterprise level Architectural Design Tactical Operational Enterprise architecture strategy and projects Operational Business and IM System
35 Blueprint versus development plan Blueprint Uniform high level of detail. Highly detailed goals, masterplan, grand design. Development plan More attention to direction, direction and guidelines. Higher levels of details per project, architecture is detailed ‘as we go’
36 Architecture and planning “IST” 3. “Next minute” steps and guidelines “SOLL” 2. Tomorrow-architecture 1. Today-architectuur “new development”
37 Speed versus cohesion Business goal ICT- solution “quick and dirty” developers “slowing” architects
DYA principles Architecture is as strategic as IT Architecture must be able to go fast (as fast as the business requires) The strategic dialogue business – IT is central to architecture Business goals drive the architecture effort Architecture should ride the wave of business and organizational change Just enough, just in time architecture Different scenarios for reaching business goals should be considered. Scenario choices may have implicatiotions for the involvement of architecture. Embedding in the organization of the ‘working with architecture’ required www.vka.nl39
40 DYA working model Business architecture Business architecture Information architecture Information architecture Technical architecture Technical architecture New developments Governance Dynamic Architecture Strategic Dialogue Strategic Dialogue Develop without architecture Develop with architecture Architecture Services Architecture Services DYA processes ICT solutions
42 With or without architecture Scenarios re strategic situation in DYA defensive, the organization is taken by surprise without architecture offensive, the organization jumps at an opportunity and an ICT solution without architecture Anticipatory, the organization with architecture With architecture: architecture artefacts, starting with (outline?) Project Start Architecture Without architecture: no architecture artefacts; ensuring convergence through management letter
44 Project Start Architecture At the start of all projects ‘with architecture’ Contains Relationship to enterprise architecture: comply or explain Analysis of process, information and IT interdependencies / boundaries Risk analysis + advice re. Architecture Acceptable solution space Interesting Analogon to business case in Prince 2 ? However, business case is updated and evaluated in all project phases. Good idea for project architecture?
45 Enterprise architecture applied Information PlanningICT solutions Development with architecture Apply architecture Facilitate Support Information planning Deliver Project Start- Architecture Apply architecture Control Architecture auditControl executionArchitecture auditManagement- letter
46 Adapt to architecture maturity ManagementDefinitionsRole architect ProcessProducts Niveau 1 Initial No steeringFirst attempts Not assignedNoneRough idea Niveau 2 Repeatable PersonsDefined but discussion AssignedPer domainUniform per domain Niveau 3 Defined ProcessDefined and accepted Responsible for process Cross domain coordinated Uniform cross domain Niveau 4 Managed ResultatsDefined and accepted Responsible for results IntegratedCentrally coordinated Niveau 5 Optimizing Continuous improvement Defined and accepted Initiates innovation and improvement OptimizedAdapted to new situation Bron: DYA (2002)
47 TOGAF Rapidly gaining support ADM cycle = Process model Collection of best practices, models, checklists Architecture function central, bureaucratic IT centered, slowly adding more business architecture
50 Role of the architect Rules and regulations Construction principles Customer Architect Contractor Form Function Durability Drivers Principles Models Standards
51 Roles of the architect Staff, advisor. A manager sometimes. Clarification of principles, priority of conflicting principles Communicator Customer Contractor Match maker Source of info Educator Introductie Arcitectuur Communicatie Praktijk
52 Question: What will a good architect never do? A.Change coffee in the coffee machine B.Hang a king size plot of his architecture model(s) on his wall C.Do small talk with the network manager D.Isolate himself in a ‘silent room’ to get his architecture right
53 De architectura, architect’s competences Theory and practice Ingeneous and Quick to study Knowledge of building materials Good writer Good at drawing Expert in mathematics Skilled in geometry and optics Knowledge of history and philosophy Acquainted with music Familiar with medicine Knowledge of jurisprudence Familiar with astronomy Vitruvius 25 B.C.
54 Architect, agent of change Power SMART Man Learn Panta rei De Caluwé
55 Recognizing resistance 1.Appointments get rescheduled 2.No (useful) information 3.Information overflow 4.Overly correct, but apparently understanding nothing 5.Having to chase every action 6."We know how it works" 7.Questioning your task
56 Architectuur, some pittfalls Splendid isolation The, by now yellow, book op the top shelf. Little support and use in the organization, no broad ‘ownership’ Master piece Lots of work initially, maintenance problematic Not for us ‘mere mortals’ Under construction no status? Ignoring architecture a practical possibility According to latest fashion … and therefore next year’s history
57 Wrong practices Technology / application preference leading Technology push Wrong level: grand schema, single system Architecture: for ICT only Architecture police versus assistance Blueprint thinking Quick fix
58 Do’s Mandate and management support What is the real assignment? Stakeholder analysis. (Have you ever met ‘the business’? It’s next to the ‘any key’.) Plan for results, identify quick wins Iterate Good = good enough Communicate, communicate, communicate ….
59 Don’ts Use the word ‘Architecture’ outside your own department Accept an architecture assignment at ‘face value’ Stick to the method, no matter what Be unaware of your counter parts interests Be (too) quick to judge Play games, hide information