Enterprise communication using archiMate

2,411 views
2,302 views

Published on

Published in: Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,411
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
81
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Remember that Guns N’ Roses album, The Spaghetti Incident?You’re forgiven if you don’t, as it wasn’t one of their best. The album was essentially a mishmash compilation of cover songs that when cobbled together didn’t sound all that great. Now think about your IT architecture, can you see a resemblance? A mishmash of technologies – new and old – all trying to work together in a spaghetti-like structure? 
  • Untangling the IT environment requires planning and management and in this presentation I will give a quick overview of some key challenges identified by research firms that will lead to even more entanglement if not managed properly.There is currently not a universality accepted definition of EA and therefore it is important to but context to the presentation, so before we start discussing standards and frameworks that address the challenges, I want to take a minute to state my definition of Enterprise Architecture.My objective with this presentation is to introduce the key frameworks and standards that provide practical guidance when tackling an EA project or implementing an EA capability.
  • JohnZachman is the father of EA and his framework is a brilliant “thinking model” to help in making sense of how to eat Elephant. He identified the value of EA to business in times of rapid change and increased complexity.As part of the EA research forum’s (consisting of academics, EA’s and business professionals) definition we included that section that EA is ongoing effort and that EA is not only a project.ISO 42010 is the best standard available that can be used to define the scope of work that needs to be done by Architects.
  • The lifecycle phases of an entity is important to understand and to note that different international frameworks and methods support different parts of the lifecycle in more or less detail.
  • Enterprise Architecture alone will not solve the spagetti structure in the organisation. We need a Governance structure to ensure that the architecture is implemented in the organisation.The IT engagement model described in Enterprise Architecture as Strategy, creating a foundation for business execution by Jeanne Ross, Peter Weill and David Robertson is in my opinion a good starting point for reviewing or implementing a governance structure around the EA effort.The IT engagement model is a system of governance mechanisms assuring that business and IT projects achieve both local and company-wide objectives.Companywide IT GovernanceProject ManagementLinking Mechanisms:Business LinkageAlignment LinkageArchitecture Linkage
  • Enterprise Architecture alone will not solve the spagetti structure in the organisation. We need a Governance structure to ensure that the architecture is implemented in the organisation.The IT engagement model described in Enterprise Architecture as Strategy, creating a foundation for business execution by Jeanne Ross, Peter Weill and David Robertson is in my opinion a good starting point for reviewing or implementing a governance structure around the EA effort.The IT engagement model is a system of governance mechanisms assuring that business and IT projects achieve both local and company-wide objectives.Companywide IT GovernanceProject ManagementLinking Mechanisms:Business LinkageAlignment LinkageArchitecture Linkage
  • There are a wide range of EA frameworks available that address some or all aspects of EA, but the question now is – Which one do I choose?Will it address the business need of managing change or reducing risk in my organisation?To answer that question we have another ISO standard
  • ISO 15704 Requirements for enterprise-reference architectures and methodologies (including the Generalised Enterprise Reference Architecture and Methodology [GERAM] addendum)The architecture aims to be a relatively simple framework upon which all the functions and activities involved in the aforementioned phases of the life of the enterprise-integration project can be mapped. It also will permit the tools used by the investigators or practitioners at each phase to be indicated. The architecture defined will apply to projects, products, and processes; as well as to enterprises.Lets step through an example where we see how the TOGAF framework support change in the organisation
  • As part of the framework we have the Generalised Enterprise Reference Architecture (GERA) entities.Understanding the fact that there are more that 1 type of entity in an organisation help with the management and planning of the EA effort.GERA identifies the following key entities:Strategic Enterprise Management Entity (Type 1)defines the necessity and the starting of any enterprise engineering / integration effort.Enterprise Engineering/Integration Entity (Entity Type 2) provides the means to carry out the enterprise engineering efforts defined by enterprise Entity Type 1. It employs a methodology (Entity Type 5) to define, design, implement and build the operation of the enterprise entity (Entity Type 3).Enterprise Entity (Entity Type 3) is the result of the operation of Entity Type 2. It uses a methodology (Entity Type 5) and the operational system provided by Entity Type 2 to define, design, implement and build the products and customer services of the enterprise (Entity Type 4).Product Entity (Entity Type 4) is the result of the operation of Entity Type 3. It represents all products and customer services of the enterprise.It is important to note that each Entity has a defined lifecycle and life history. For the purpose of our discussion today we will only look at the lifecycle.
  • Enterprise Architecture alone will not solve the spagetti structure in the organisation. We need a Governance structure to ensure that the architecture is implemented in the organisation.The IT engagement model described in Enterprise Architecture as Strategy, creating a foundation for business execution by Jeanne Ross, Peter Weill and David Robertson is in my opinion a good starting point for reviewing or implementing a governance structure around the EA effort.The IT engagement model is a system of governance mechanisms assuring that business and IT projects achieve both local and company-wide objectives.Companywide IT GovernanceProject ManagementLinking Mechanisms:Business LinkageAlignment LinkageArchitecture Linkage
  • Enterprise communication using archiMate

    1. 1. 1 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m www.csInteractiveTraining.com Enterprise Collaboration Presented by Louw Labuschagne
    2. 2. 2 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Louw is passionate about all aspects of information management and had the opportunity to act as strategist, architect, speaker, trainer, analyst, modeller and developer within this field over the past 18 years holding a strong track record at reputable organisations. Industry Contributions • Contributor to TOGAF 9 & ArchiMate 1.0 Standards • Contributor to TOGAF 9 Certification for People • Open Group white paper co-author: IT Governance • Speaker at Open Group conferences & Webinars Industry Articles • Author of several published white papers on TOGAF, Enterprise Architecture & Architecture skills Certifications • TOGAF 9 Certified Architect • Licensed ZapThink Architect • Zachman Certified • ArchiMate 2 Certified Louw Labuschagne M. Tech. Professional Practice in I.T. , MBA
    3. 3. 3 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Agenda • Business Context • The Need for Collaboration • Business Entities • Entity Lifecycles • The ArchiMate Language • Primitive & Composite Views EA as Strategy COBIT GERAM Zachman Framework TOGAF ADM ISO/IEC 38500 ArchiMate Architecture Capability SOA SOCCI ISO/IEC 42010 Open Enterprise Security Architecture
    4. 4. 4 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Board of Directors Vehicle Asset Finance Business Information Management Dealer Call Centre Service Centre Processing Centre Document Filing Retail Banking Division Home Loans Division Shared Services Division Finance Internal Audit MIS & Fin Reporting Marketing HR Performance Management Learning & Development Enterprise Program Office Project Haraka ICT Strategy & Architecture Projects & Development IT Operations Organisational Structure
    5. 5. 5 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m • The Vehicle Asset Finance is a highly paper intensive with 85000 applications received monthly. • 20% is manually faxed and contains an average of 4 pages per application. Vehicle Asset Finance Division Business Challenge: The VAF has faced a 5% loss in its market share over the past 3 years due to application processing taking longer that 4 hours per application.
    6. 6. 6 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Key Issues within the VAF Process inefficiencies Ineffective manual work distribution methods result in bottlenecks and high lag times Data Quality Issues No control over the quality of data entering the processing channel System Inefficiencies Inability to systematically track where a transaction is in the process Deterioration in sales relationships Accountability for service breakdowns can‟t be identified (Blaming) Vehicle Asset Finance Division
    7. 7. 7 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m • There is an on-going initiative in Imali Bank to make the business paperless, resulting in an increased importance ascribed to the value of Business Process Management (BPM) systems. • This has led to Imali bank‟s decision to implement a BPM solution in the Vehicle Asset Finance (VAF) environment to manage the administration of vehicle asset finance applications. • To ensure maximum business process efficiency the business processes in the VAF service centre and processing centre will be reengineered in parallel with the implementation of the BPM solution. Project Haraka – Automating Vehicle Asset Finance
    8. 8. 8 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Business Need
    9. 9. 9 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m How would you solve the issues in the VAF Division? • Update the systems on a trial and error basis.. High Risk
    10. 10. 10 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m • Appoint a professional person to help update the system.. How would you solve the issues in the VAF Division? Time consuming Expensive
    11. 11. 11 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m • The current system reached end-of-life; Replace with a new system How would you solve the issues in the VAF Division? Decommission Build from scratch
    12. 12. 12 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Answer: Enterprise Architecture "If you get really honest and search all of history, seven thousand years of known history of humankind, to find how humanity has learned to cope with two things, complexity and change… there is one game in town, ARCHITECTURE.” John Zachman ISO/IEC 42010:2007 defines “architecture” as: “The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” Enterprise Architecture is the continuous practice of describing the essential elements of a socio-technical organisation, their relationships to each other and to the environment, in order to understand complexity and manage change. - Enterprise Architecture Research Forum (EARF)
    13. 13. 13 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Built Environment Lifecycle Concept Design Installation
    14. 14. 14 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m ISO 15704 Requirements for enterprise- reference architectures and methodologies • its initial concept in the eyes of the entrepreneurs who initially developed it, • through its definition, • functional design or specification, • detailed design, • physical implementation or construction, • and finally operation • to obsolescence. Generalised Enterprise Reference Architecture and Methodology (GERAM) is an enterprise-reference architecture that models the whole life history of an enterprise integration project from Identification Concept Requirements Preliminary Design Detailed Design Implementation Operation Decommission EntityLife-cyclePhases
    15. 15. 15 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Product Lifecycle 1. Identification 2. Concept 3. Requirements 4. Preliminary Design 5. Detailed Design 6. Implementation 7. Operation 8. Decommission ISO 15704 GERAM Life-cycle Phases
    16. 16. 16 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Architecture 1. Identification 2. Concept 3. Requirements 4. Preliminary Design 5. Detailed Design 6. Implementation 7. Operation 8. Decommission
    17. 17. 17 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Zachman Framework for Enterprise Architecture has become a de facto standard for classifying the artifacts developed in enterprise architecture. It is a logical structure for classifying and organising the design artifacts of an enterprise that are significant to its management. The Zachman Framework is: • Simple – easy to understand, not technical, but logical. • Comprehensive – it addresses the Enterprise in its entirety. • a Language – helps to communicate complex concepts precisely with few, non-technical words. • a Planning tool – position issues in the context of the Enterprise and assists with making better choices. • a Problem-solving tool – working with abstractions allows for the isolation of simple variables without losing the sense of complexity of the Enterprise as a whole. The Zachman Framework
    18. 18. 18 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m • Strategic Information – Organised Information about the environment • Markets • Customers / non-customers • Technology Trends • World-wide Finance / Changing world economy • Tactical Information – Foundation Information – Productivity Information – Competence Information – Resource Allocation Information • Operational Information – Accounting Information -> focused on lowering cost – Cost accounting / Total Quality Management Business Success is based on Creating Value and Wealth and not in just controlling costs – Peter Drucker Enterprise Architecture Value Contribution
    19. 19. 19 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Several disciplines are involved in the enterprise change process Change Process Management Science Industrial Engineering Control Engineering Information & Communication Technology
    20. 20. 20 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Entity Life cycle
    21. 21. 21 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Strategic Management Entity (Type 1) defines the necessity and the starting of any enterprise engineering / integration effort. Engineering Entity (Type 2) provides the means to carry out the enterprise engineering efforts defined by enterprise Entity Type 1. Construction Entity (Type 2) provides the means to carry out the enterprise engineering efforts defined by enterprise Entity Type 1. Manufacturing Entity (Type 3) is the result of the operation of Entity Type 2. It uses the operational system provided by Entity Type 2 to define, design, implement and build the products and customer services of the enterprise (Entity Type 4). ISO 15704 GERAM Entity Types & Entity Life-cycle Phases 1. Identification 2. Concept 3. Requirements 4. Preliminary Design 5. Detailed Design 6. Implementation 7. Operation 8. Decommission Product: Enterprise Concept Product: Enterprise Design Product: Enterprise Installation Enterprise Product (Type 4) is the result of the operation of Entity Type 3. It represents all products and customer services of the enterprise.
    22. 22. 22 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Board of Directors Vehicle Asset Finance Business Information Management Dealer Call Centre Service Centre Processing Centre Document Filing Retail Banking Division Home Loans Division Shared Services Division Finance Internal Audit MIS & Fin Reporting Marketing HR Performance Management Learning & Development Enterprise Program Office Project Haraka ICT Strategy & Architecture Projects & Development IT Operations Strategic Management Entity (Type 1) defines the necessity and the starting of any enterprise engineering / integration effort. Construction Entity (Type 2) provides the means to carry out the enterprise engineering efforts defined by enterprise Entity Type 1. Engineering Entity (Type 2) provides the means to carry out the enterprise engineering efforts defined by enterprise Entity Type 1. Manufacturing Entity (Type 3) is the result of the operation of Entity Type 2. It uses the operational system provided by Entity Type 2 to define, design, implement and build the products and customer services of the enterprise (Entity Type 4). ISO 15704 GERAM Entity Types Engineering Entity (Type 2) provides the means to carry out the enterprise engineering efforts defined by enterprise Entity Type 1. Construction Entity (Type 2) provides the means to carry out the enterprise engineering efforts defined by enterprise Entity Type 1.
    23. 23. 23 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Imali Bank Vehicle Asset Finance Electronic Application Service (i-VAF) • To optimise business processes i-VAF will provide full end-to-end management of each vehicle asset finance application. • i-VAF will provide full process and status visibility of application transactions at all interfacing points. – The visibility that is gained will enable continuous improvement to eliminate waste from processes and improve turnaround time and costs. – Quality assurance will be incorporated earlier in the lifecycle and feedback required during the process will be automated where necessary. – All manual forms and other supporting documentation related to applications will be electronically available and greatly reduce the need for paper. • i-VAF will provide the capability to allocate work based on business rules as well as re-prioritise and re-allocate work when required. – Full business activity monitoring will be available across the end-to-end vehicle asset finance application management process with service level agreements and escalation management. Enterprise Product (Type 4) is the result of the operation of Entity Type 3. It represents all products and customer services of the enterprise.
    24. 24. 24 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Project Management Companywide IT Governance IT Engagement Model* Company strategy & operations Project plan Solution Architecture Enterprise architecture Alignment Coordination Business Linkage • Business sponsors for projects • Regular project reviews by company level office • Process owners • Incentives tied to company goals Architecture Linkage • Architect on projects • Project funding based on Architecture compliance • Architect training Project Level Company Level ITBusiness Alignment Linkage • Project Management Office • Business – IT relationship managers • Project manager training *Based on the model defined in Enterprise Architecture as Strategy (Ross, Weill & Robertson) ISO 38500:2008 ISO 21500:2012 ISO/IEC 20000: 2005
    25. 25. 26 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m AAF Automotive Architecture Framework BCA Business Capability Architecture BEAM Business Enterprise Architecure Modeling BPEAM iteratec best-practice enterprise architecture management (EAM) method CEA CEA Framework: A Service Oriented Enterprise Architecture Framework (SOEAF) CIAF Capgemini Integrated Architecture Framework DoDAF US Department of Defense Architecture Framework DRA1 Dragon1 E2AF Extended Enterprise Architecture Framework EXAF Extreme Architecture Framework FEAF US Federal Enterprise Architecture Framework FFLV+GODS Functions-Flows-Layers-Views + Governance- Operations-Development-Support FSAM Federal Segment Architecture Methodology (FSAM) GEAF Gartner's Enterprise Architecture Framework HEAF Health Enterprise Architecture Framework Enterprise Architecture Frameworks ICODE iCode Security Architecture Framework IFW IBM Information FrameWork (IFW) 4+1 Kruchten's 4+1 view model MODAF (UK) Ministry of Defence Architecture Framework NAF NATO C3 Systems Architecture Framework NIST-EAM NIST Enterprise Architecture Model PEAF Pragmatic Enterprise Architecture Framework PPOOA Processes Pipelines in Object Oriented Architectures SABSA Sherwood Applied Business Security Architecture TEAF (US) Treasury Enterprise Architecture Framework TOGAF The Open Group Architecture Framework xAF Extensible Architecture Framework ZF Zachman Framework IADS IBM Architecture Description Standard IAF Index Architecture Framework
    26. 26. 27 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m IFIP-IFAC Task Force, 1999) ISO 15704 Requirements for enterprise-reference architectures and methodologies GERA Identifies concepts of enterprise integration EEM Describe process of enterprise engineering EMLs Provide modelling constructs for modelling enterprise concepts EETs Support enterprise engineering GEMCs Define the meaning of enterprise modelling constructs PEMs Provide reusable reference models and designs of enterprise concepts EMs Enterprise designs, and models to support analysis and operationEMOs Provide implementable modules (human, process & technology) EOS Support the operation of the particular enterprise employs utilise Implemented in support Used to build Used to implement (Particular) Enterprise Operational Systems Human Concepts Technology Concepts Process Concepts Generic Enterprise Reference Architecture Enterprise Engineering Methodology Enterprise Modelling Languages Partial Enterprise Models Generic Enterprise Modelling Concepts Enterprise Modules (Particular) Enterprise Models Enterprise Engineering Tools Strategic Management Entity (Type 1) Construction Entity (Type 2) Engineering Entity (Type 2) Enterprise Product (Type 4) Manufacturi ng Entity (Type 3) Methodology Entity (Type 5) Enterprise Engineering Tool
    27. 27. 28 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Architecture Development Method (ADM) is an iterative approach to planning, designing, realising, and governing the change effort. ISO 38500:2008 ISO 21500:2012 ISO/IEC 15504 (SPICE) ISO/IEC 20000: 2005 Identification Concept Requirements Preliminary Design Detailed Design Implementation Operation Decommission
    28. 28. 29 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m ArchiMate
    29. 29. 30 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m ArchiMate 2 and the TOGAF® ADM • ArchiMate Core – Enables modeling of the architecture domains defined by TOGAF • Motivation Extension – Enables modeling of stakeholders, drivers for change, business goals, principles and requirements • Implementation and Migration Extension – Enables modeling of project portfolio management, gap analysis and transition and migration planning
    30. 30. 31 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Have you ever seen the following happen? THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG A A B B C C D D E E F F M M N N O O P P Q Q R R G G H H I I J J K K L L S S T T U U V V W W X X Y Y Z Z Apply English Language Rules
    31. 31. 32 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Can you now answer the question? THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG ...Because everyone in the room were taught the english language rules ...  Standard form for each shape  Standard spelling for using shapes  Standard pronunciations for each shape  Standard meanings of each shape  Standard rules for the use of shapes
    32. 32. 33 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Key requirements of an Enterprise Architecture Modelling Language  Focused on modelling inter-domain relations  Modelling the global structure within each domain, showing the main elements and their dependencies, in a way that is easy to understand for non-experts of the domain  Models must be interpreted in an unambiguous way  Visualise models in a different way, tailored towards specific stakeholders with specific information requirements
    33. 33. 34 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Introduction to [Ahr-ki-meyt] • ArchiMate provides instruments to support enterprise architects in describing, analysing and visualising the relationships among business domains in an unambiguous way • ArchiMate is an open and independent modelling language for enterprise architecture • Supported by leading EA tool vendors • Tailored towards specific stakeholders addressing specific information requirements
    34. 34. 35 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Layered Services Approach Application Layer The Application layer supports the business layer with application services which are realised by (software) applications. Business Layer The Business layer offers products and services to external customers, which are realised in the organisation by business processes performed by business actors. Technology Layer The Technology layer offers infrastructural services (e.g., processing, storage and communication services) needed to run applications, realised by computer and communication hardware and system software. A service is defined as a unit of functionality that some entity (e.g., a system, organisation or department) makes available to its environment, and which has some value for certain entities in the environment.
    35. 35. 36 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Language Elements • Behavioural or dynamic aspect – Behavioural concepts are assigned to structural concepts, to show who or what displays the behaviour • Structural or static aspect – Active structural elements • the business actors, application components and devices that display actual behaviour, i.e., the „subjects‟ of activity – Passive structural elements • i.e., the objects on which behaviour is performed • External view and an internal view – For the external users, only this external functionality, together with non-functional aspects such as the quality of service, costs etc., are relevant
    36. 36. 37 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Generic Metamodel – Core Concepts of ArchiMate
    37. 37. 38 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m
    38. 38. 39 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m
    39. 39. 40 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Practical: Model the following in your favourite modelling tool
    40. 40. 41 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m • Now that you have a basic overview of the open day process as it is, let's see what happens when we extend the use of the new CRM package. To understand how that will work, we need to break apart the services that the applications provide, and represent them in a separate 'services' layer, between the application layer and the business layer. It will contain: • • The MS Exchange package realises the email service • The CRM package realises: – a Marketing Service – a CRM e-mail Service – a Print Open Day Register Service Add Services Layer
    41. 41. 42 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m • These services are particularly widely used inside the Open Day Planning process, so we'll make that process box bigger and we'll put a number of sub-processes inside of it. It starts with: • a Confirm Room Booking process, which triggers both: – an E-mail staff process, which triggers: • a Book Catering process, which triggers: • a Check and Update Signage process, which triggers both: – a Print PGCE process – an Update Materials process, which triggers: – the same Print PGCE process – a Create Marketing list process, which triggers: • an Attach Marketing List to Event process, which triggers: • an E-mail Marketing List process, which triggers: • an Add Planning Tasks process, which triggers: • the same Update Materials process Add Sub-processes
    42. 42. 43 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Now that the process has been elaborated, we can connect which services are used to make these processes happen. • The Marketing Service is used by: – Create Marketing List process – Attach Marketing List to Event process – Add Planning Tasks process • The E-mail Service is used by: – Confirm Room Booking process, – E-mail staff process – Send Update to Subject Staff process • The CRM E-mail Service is used by: – E-mail Marketing List process • The Print Open Day Register Service is used by: – Print Open Day Register process Link Services to processes
    43. 43. 44 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m • In addition, there now is a Role of "Open Day planner" who has been assigned all processes in the open day planning model. • The role has been assigned to the actor "Sue". Add Role
    44. 44. 45 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m • The model is fairly comprehensive, but also a bit hairy. • It's just too complex to show to most stakeholders. • That's why we want to create a new view on the same model. • The ArchiMate specification itself specifies 18 views for various purposes, but ArchiMate Modelling Tool will happily let you make your own view. • In each case, the important point is to be clear what the view is meant to achieve or convey, and for what stakeholders it is intended. • For this exercise: – Pick your goal – Pick your target group – Limit the number of entities in the view to the ideal: seven, plus or minus two Views
    45. 45. 46 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Architecture 1. Identification 2. Concept 3. Requirements 4. Preliminary Design 5. Detailed Design 6. Implementation 7. Operation 8. Decommission
    46. 46. 47 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Zachman Framework  Row 2 – Conceptually define what the owners have in mind  Row 3 – How will the Enterprise concepts be realised systematically  Row 4 – Enterprise implementation based on general technology constraints  Row 5 –Specify the implementations to specific technology products  Row 6 – Functioning Enterprise 1 3 2 4 5 6  Row 1 – Boundaries of the Enterprise, what is included The Zachman Framework consists of a six by six matrix with each row representing a different perspective on the enterprise. Row 1 is the most abstract view, with each following row representing more detail and concrete views of the enterprise until Row 6 that are the functioning enterprise.
    47. 47. 48 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Zachman Framework Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Why Who Who When When Where Where What What How How  Rule 2: Each column has a simple, basic model  Rule 3: Basic model of each column is unique  Rule 4: Each row represents a distinct view  Rule 5: Each cell is unique  Rule 6: Combining the cells in one row forms a complete description from that view Basic Model = Entities and Relationships Entity Relationship Entity  Rule 1: Columns have no order The Zachman Framework Rules
    48. 48. 49 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Zachman Framework • External Requirements and Drivers • Business Function Modeling  Function/How List of processes the business perform High-level business functions  Data/What List of things important to the business  People/Who List of Organisations important to the business  Network/Where List of locations in which the business operates  Time/When List of events significant to the business 1  Motivation/Why List of business goals and strategies Row 1: Scope/Planner’s View
    49. 49. 50 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Motivation Extension Metamodel
    50. 50. 51 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Example Motivation Extension Model
    51. 51. 52 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Zachman Framework • Business Process Models • Business Function Allocation • Elimination of Function Overlap and Ambiguity  Function/How Business processes  Data/What Business data  People/Who Roles and responsibilities in each process  Network/Where Locations related to each process  Time/When Events for each process and sequencing of integration and process improvements 2  Motivation/Why Policies, procedures and standards for each process Row 2: Enterprise Model/Designer’s View
    52. 52. 53 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Business Layer Metamodel
    53. 53. 54 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Example Business Layer Model
    54. 54. 55 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Zachman Framework • Logical Models • Project Management • Requirements Definition  Function/How Logical representation of information systems and their relationships  Data/What Logical data models of data and data relationships underlying information  People/Who Logical representation of access privileges constrained by roles and responsibilities  Network/Where Logical representation of the distributed system architecture for locations  Time/When Logical events and their triggered responses constrained by business events and their responses 3  Motivation/Why Policies, standards and procedures associated with a business rule model Row 3: System Model/Designer’s View
    55. 55. 56 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Application Layer Metamodel
    56. 56. 57 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Example Application Layer Model
    57. 57. 58 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Zachman Framework • Physical Models • Technology Management • Solution Definition and Development  Function/How Specifications of applications that operate on particular technology platforms  Data/What Database management system (DBMS) type requirements constrained by logical data models  People/Who Specification of access privileges to specific platforms and technologies  Network/Where Specification of network devices and their relationships within physical boundaries  Time/When Specification of triggers to respond to system events on specific platforms and technologies 4  Motivation/Why `Business rules constrained by information systems standards Row 4: Technology Model/Builder’s View
    58. 58. 59 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Technology Layer Metamodel
    59. 59. 60 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Example Technology Layer Model
    60. 60. 61 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Zachman Framework • Configuration Management • Deployment  Function/How Programs coded to operate on specific technology platforms  Data/What Data definitions constrained by physical data models  People/Who Access privileges coded to control access to specific platforms and technologies  Network/Where Network devices configured to conform to node specifications  Time/When Timing definitions coded to sequence activities on specific platforms and technologies 5  Motivation/Why Business rules constrained by specific technology standards Row 5: As-Built/Integrator’s View
    61. 61. 62 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m The Zachman Framework • Functioning Enterprise • Operations Management • Evaluation  Function/How Functioning computer instructions  Data/What Data values stored in actual databases  People/Who Personnel and key stakeholders working within their roles and responsibilities  Network/Where Sending and receiving messages  Time/When Timing definitions operating to sequence activities 6 Motivation/Why Operating characteristics of specific technologies constrained by standards Row 6: Functioning Enterprise/User’s View
    62. 62. 63 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Implementation & Migration Extension Metamodel
    63. 63. 64 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Example Implementation & Migration Model
    64. 64. 65 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m
    65. 65. 66 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m
    66. 66. 67 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m
    67. 67. 68 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m
    68. 68. 69 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m ArchiMate 2 Summary
    69. 69. 75 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m Business owners need to realise that their enterprise architecture design is a reflection of their business even if it is not intentional. If you don‟t care about your enterprise architecture then your design is telling people that you don‟t care about your business. — MARCO SUAREZ (SLIGHTLY ADAPTED)

    ×