Presentation is loading. Please wait.

Presentation is loading. Please wait.

Enterprise architecture Being succesful as an architect TopTech, 22-04-2010 Rene van den Assem.

Similar presentations


Presentation on theme: "Enterprise architecture Being succesful as an architect TopTech, 22-04-2010 Rene van den Assem."— Presentation transcript:

1 Enterprise architecture Being succesful as an architect TopTech, Rene van den Assem

2 Meet… VKA Verdonck, Klooster en Associates Independent consultancy Strategic projects with ICT

3 Meet… VKA Since 1985 €17,2 million in people small 95% of customers come back repeatedly

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

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

8 Views of enterprise architecture ANSI / IEEE 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 9 A definition ANSI / IEEE 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 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 Conceptual framework Viewpoint

11 11 Viewpoints en Modaliteiten: Zachman Enterprise Architecture

12 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

13 13

14 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 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

16 16 Enterprise architecture, the process

17 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 18 Artist impression versus ‘under the hood’ Artist impression Managers, general public Under the hood Architects Process and IT designers

19 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

20 Principles, format Format Name Statement Rationale Implications Optional: Relation to external sources (strategy & policy documents) Relation to other principles 20

21 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

22 22 Technical Obstacles Rationale Technical principles Implications Functional principles Rationale Implications Obstacles Functional Linking principles Implementation principles Rationale Implications Obstacles Implementation Business Actions Business drivers Goals Business principles Rationale Implications Obstacles Actions

23 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

24 How to do principles ? Under the hood Attempt completeness 100+ Exact statements Direction, boundary conditions, construction Artist impression Only the essential max Catchy phrasing Focus on direction, behaviour, mostly business principles

25 Models 25

26 Question: Why use models? A.The method says so B.One picture > 1000 words C.Simplify D.Why not

27 Assignment: draw a chicken (kip)

28 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

29 Views of the world: population

30 age100+

31 patents & licences

32 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

33 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 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 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 36 Architecture and planning “IST” 3. “Next minute” steps and guidelines “SOLL” 2. Tomorrow-architecture 1. Today-architectuur “new development”

37 37 Speed versus cohesion Business goal ICT- solution “quick and dirty” developers “slowing” architects

38 38 DYA: speed and cohesion

39 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

40 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

41 Strategic alignment

42 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

43 DYA architect meets Prince2 Phase Starting Up Phase Initiation Project Mandate Architectuur § Project Brief PSA PID Advice pre- mandate

44 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 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 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 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

48 TOGAF Architecture governance

49 Architecture governance, consider Dependencies Activity wise Information Infrastructure Structure, Cohesion, Uniformity: project, programmes, systems Architectural priorities Project Portfolio Board =? Architecture Board

50 50 Role of the architect Rules and regulations Construction principles Customer Architect Contractor Form Function Durability Drivers Principles Models Standards

51 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 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 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 54 Architect, agent of change Power SMART Man Learn Panta rei De Caluwé

55 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 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 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 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 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

60 60 Architect(ure), the bridge to the future

61


Download ppt "Enterprise architecture Being succesful as an architect TopTech, 22-04-2010 Rene van den Assem."

Similar presentations


Ads by Google