Enterprise Architecture can quickly become difficult to communicate.<\/p>\n
A business executive talks about customer outcomes. A product manager talks about products and capabilities. A software architect talks about applications, APIs, and microservices. An infrastructure architect talks about Kubernetes clusters, networks, databases, and cloud platforms.<\/p>\n
All of them may be discussing the same system \u2014 but using completely different languages.<\/p>\n
This is the problem that ArchiMate\u00ae<\/strong> is designed to solve.<\/p>\n ArchiMate is an open Enterprise Architecture modelling language maintained by The Open Group<\/strong>. It provides architects with a standardized vocabulary for describing organizations, business processes, applications, information, technology infrastructure, strategy, motivation, and transformation.<\/p>\n The current specification is ArchiMate 3.2<\/strong>, released in October 2022.<\/p>\n In this tutorial, we will learn enough ArchiMate to start creating useful architecture models without attempting to memorize the entire specification.<\/p>\n More importantly, we will look at four practical examples showing how ArchiMate can support architects working according to the Open Agile Architecture\u2122 (O-AA\u2122) Standard<\/strong>.<\/p>\n Before looking at the notation, it is important to distinguish the two.<\/p>\n Open Agile Architecture (O-AA)<\/strong> provides an approach to architecture suitable for digital and Agile organizations.<\/p>\n Among other things, O-AA emphasizes:<\/p>\n The Open Group describes O-AA as an outcome-based, customer-focused, and product-centered approach<\/strong> to architecture.<\/p>\n ArchiMate<\/strong>, on the other hand, gives us a language with which we can draw those architectures.<\/p>\n Think of the distinction like this:<\/p>\n O-AA tells us how to think about Agile Architecture. ArchiMate gives us a language for describing what we have designed.<\/strong><\/p><\/blockquote>\n They are therefore highly complementary.<\/p>\n The Open Group has also published guidance specifically addressing Agile Architecture modelling using the ArchiMate language<\/strong>, including using models to support communication, collaboration, decision-making, and enterprise agility.<\/p>\n Most architects can draw something resembling architecture with PowerPoint, Visio, draw.io, or a whiteboard.<\/p>\n The problem is that a box labelled “Payment Engine”<\/strong> could mean almost anything.<\/p>\n Is it:<\/p>\n ArchiMate removes much of this ambiguity.<\/p>\n A particular type of element has a defined architectural meaning.<\/p>\n That makes models easier to:<\/p>\n The Open Group describes ArchiMate’s value as providing a common language for describing and relating business processes, organizational structures, information flows, IT systems, and technical infrastructure.<\/p>\n Do not begin by memorizing dozens of symbols.<\/p>\n Instead, remember this chain:<\/p>\n WHY \u2192 WHAT \u2192 HOW \u2192 WITH WHAT \u2192 CHANGE<\/strong><\/p>\n In ArchiMate terms, this roughly becomes:<\/p>\n Motivation \u2192 Strategy \u2192 Business \u2192 Application \u2192 Technology \u2192 Implementation<\/strong><\/p>\n Consider a digital bank.<\/p>\n The bank might say:<\/p>\n WHY<\/strong><\/p>\n Customers abandon our account-opening journey.<\/p><\/blockquote>\n Therefore:<\/p>\n STRATEGY<\/strong><\/p>\n We need a Digital Customer Onboarding capability.<\/p><\/blockquote>\n Which requires a:<\/p>\n BUSINESS<\/strong><\/p>\n Customer Verification Process.<\/p><\/blockquote>\n Supported by an:<\/p>\n APPLICATION<\/strong><\/p>\n KYC Application Service.<\/p><\/blockquote>\n Provided by an:<\/p>\n APPLICATION COMPONENT<\/strong><\/p>\n Identity Verification Platform.<\/p><\/blockquote>\n Running on:<\/p>\n TECHNOLOGY<\/strong><\/p>\n Kubernetes and cloud infrastructure.<\/p><\/blockquote>\n Delivered through a:<\/p>\n CHANGE INITIATIVE<\/strong><\/p>\n Digital Onboarding Modernization Program.<\/p><\/blockquote>\n That entire chain can be represented using ArchiMate.<\/p>\n And that is where ArchiMate becomes considerably more powerful than drawing disconnected infrastructure diagrams.<\/p>\n A useful beginner’s mental model is to divide ArchiMate into several areas.<\/p>\n Motivation explains why something should change<\/strong>.<\/p>\n Common elements include:<\/p>\n For example:<\/p>\n Driver:<\/strong> Customers expect instant onboarding<\/p>\n \u2193<\/p>\n Goal:<\/strong> Reduce onboarding time<\/p>\n \u2193<\/p>\n Requirement:<\/strong> Identity verification must complete within 30 seconds<\/p>\n Motivation is particularly important in an O-AA environment because architecture should be connected to business and customer outcomes<\/strong>, rather than technology existing for its own sake.<\/p>\n The Strategy domain helps describe what the organization needs to be capable of doing<\/strong>.<\/p>\n Important elements include:<\/p>\n A capability answers:<\/p>\n What must the enterprise be able to do?<\/strong><\/p><\/blockquote>\n Examples might include:<\/p>\n Notice that a capability does not specify which software performs the work.<\/p>\n That separation is extremely useful.<\/p>\n You might replace ten applications over five years while the Payment Processing Capability<\/strong> remains necessary.<\/p>\n The Business Layer describes what the organization actually does.<\/p>\n Typical elements include:<\/p>\n For example:<\/p>\n Business Role<\/strong><\/p>\n Customer Service Agent<\/p>\n \u2193<\/p>\n performs<\/p>\n Business Process<\/strong><\/p>\n Resolve Customer Dispute<\/p>\n \u2193<\/p>\n uses<\/p>\n Business Object<\/strong><\/p>\n Dispute Case<\/p>\n The Business Layer provides the connection between high-level strategy and the systems that support the organization.<\/p>\n The Application Layer describes software systems and the services they provide.<\/p>\n Some of the most useful beginner elements are:<\/p>\n For example:<\/p>\n Application Component<\/strong><\/p>\n Fraud Management System<\/p>\n \u2193<\/p>\n provides<\/p>\n Application Service<\/strong><\/p>\n Transaction Risk Scoring<\/p>\n \u2193<\/p>\n serves<\/p>\n Business Process<\/strong><\/p>\n Authorize Payment<\/p>\n This distinction between a component and a service is important.<\/p>\n The component<\/strong> is the software.<\/p>\n The service<\/strong> represents functionality that software exposes to its consumers.<\/p>\n The Technology Layer describes the infrastructure supporting applications.<\/p>\n Common elements include:<\/p>\n For example:<\/p>\n Application Component<\/strong><\/p>\n Payment API<\/p>\n \u2193<\/p>\n deployed on<\/p>\n Node<\/strong><\/p>\n Kubernetes Cluster<\/p>\n \u2193<\/p>\n uses<\/p>\n Technology Service<\/strong><\/p>\n Managed PostgreSQL Service<\/p>\n \u2193<\/p>\n hosted within<\/p>\n Node<\/strong><\/p>\n Cloud Platform<\/p>\n This lets an architect trace dependencies from a business capability all the way down to infrastructure.<\/p>\n Architects must model not only the current and future states but also how the organization moves between them<\/strong>.<\/p>\n Useful elements therefore include:<\/p>\n For example:<\/p>\n Current Plateau<\/strong><\/p>\n Monolithic Payments Platform<\/p>\n \u2193<\/p>\n Gap<\/strong><\/p>\n Cannot scale payment services independently<\/p>\n \u2193<\/p>\n Work Package<\/strong><\/p>\n Payments Microservices Migration<\/p>\n \u2193<\/p>\n Target Plateau<\/strong><\/p>\n Cloud-Native Payments Platform<\/p>\n This becomes particularly valuable when architecture is treated as something that continuously evolves<\/strong>, rather than a document produced once every three years.<\/p>\n There is another useful ArchiMate concept beginners should understand.<\/p>\n Within the core layers, elements broadly describe three things.<\/p>\n Examples:<\/p>\n Examples:<\/p>\n Examples:<\/p>\n A simple example is:<\/p>\n Customer Service Application<\/strong><\/p>\n Active Structure<\/p>\n \u2193<\/p>\n performs<\/p>\n Update Customer Details<\/strong><\/p>\n Behavior<\/p>\n \u2193<\/p>\n accesses<\/p>\n Customer Record<\/strong><\/p>\n Passive Structure<\/p>\n This structure-behavior-information pattern repeats throughout ArchiMate and makes the language much easier to learn.<\/p>\n Knowing the elements is only half of the language.<\/p>\n The other half is understanding how they relate.<\/p>\n Fortunately, beginners can do a great deal with only a handful of relationships.<\/p>\n Means:<\/p>\n This thing consists of these things.<\/p><\/blockquote>\n For example:<\/p>\n Digital Banking Platform<\/p>\n composed of<\/strong><\/p>\n Generally expresses responsibility for performing behavior.<\/p>\n For example:<\/p>\n Fraud Analyst<\/p>\n assigned to<\/strong><\/p>\n Investigate Fraud Alert<\/p>\n Means that something implements or provides a more abstract concept.<\/p>\n For example:<\/p>\n Payment Processing Function<\/p>\n realizes<\/strong><\/p>\n Payment Processing Service<\/p>\n Means that one element provides functionality to another.<\/p>\n For example:<\/p>\n Authentication Service<\/p>\n serves<\/strong><\/p>\n Mobile Banking Application<\/p>\n Shows that behavior or structure reads or changes information.<\/p>\n For example:<\/p>\n Payment Processing Function<\/p>\n accesses<\/strong><\/p>\n Transaction Data<\/p>\n Represents the transfer of something.<\/p>\n For example:<\/p>\n Payment Gateway<\/p>\n flows transaction information to<\/strong><\/p>\n Fraud Detection System<\/p>\n Represents a temporal or causal relationship.<\/p>\n For example:<\/p>\n Receive Payment Request<\/p>\n triggers<\/strong><\/p>\n Validate Payment<\/p>\n which triggers:<\/p>\n Fraud Check<\/p>\n which triggers:<\/p>\n Authorize Transaction<\/p>\n You do not need to master every ArchiMate relationship before producing useful models.<\/p>\n Start with these.<\/p>\n One of the most important ArchiMate lessons is:<\/p>\n The complete model is not the diagram.<\/strong><\/p><\/blockquote>\n Your architecture repository might contain thousands of interconnected elements.<\/p>\n A CEO should not see all of them.<\/p>\n Neither should a developer.<\/p>\n Instead, you create views<\/strong> showing only the information relevant to a particular concern.<\/p>\n The ArchiMate community guidance describes a viewpoint as conventions used to create a view addressing a known stakeholder concern.<\/p>\n For example:<\/p>\n Show:<\/p>\n Strategy \u2192 Outcomes \u2192 Capabilities \u2192 Products<\/p>\n Show:<\/p>\n Product \u2192 Value Stream \u2192 Business Processes \u2192 Applications<\/p>\n Show:<\/p>\n Applications \u2192 Services \u2192 APIs \u2192 Data<\/p>\n Show:<\/p>\n Applications \u2192 Runtime Platforms \u2192 Networks \u2192 Databases<\/p>\n Show:<\/p>\n Requirements \u2192 Applications \u2192 Information \u2192 Security Controls<\/p>\n All of these views can come from the same underlying ArchiMate model<\/strong>.<\/p>\n The following four examples show how ArchiMate can help architects apply important ideas associated with Open Agile Architecture.<\/p>\n The diagrams below use simplified text notation for readability:<\/p>\n Arrows illustrate architectural relationships conceptually rather than attempting to reproduce every graphical symbol from the specification.<\/p>\n A digital bank discovers that 35% of prospective customers abandon account registration before completing identity verification.<\/p>\n The traditional architecture response might immediately be:<\/p>\n “We need to replace the KYC system.”<\/p><\/blockquote>\n But that jumps from problem to solution.<\/p>\n An O-AA-style approach starts with the desired outcome<\/strong>.<\/p>\n O-AA explicitly emphasizes outcome-based and customer-focused architecture.<\/p>\n ArchiMate allows us to maintain that traceability.<\/p>\n Now we understand why<\/strong> architecture needs to change.<\/p>\n The organization needs the ability to perform digital onboarding effectively.<\/p>\n Now we can identify where the customer experiences friction.<\/p>\n The Verify Identity<\/strong> stage might depend on:<\/p>\n We now have traceability from:<\/p>\n Customer \u2192 Outcome \u2192 Capability \u2192 Journey \u2192 Process \u2192 Application \u2192 Infrastructure<\/strong><\/p>\n That is much more valuable than simply drawing a diagram containing “KYC Server”.<\/p>\n It keeps architects focused on the question:<\/p>\n “What customer or business outcome are we trying to achieve?”<\/p><\/blockquote>\n rather than:<\/p>\n “What technology should we deploy?”<\/p><\/blockquote>\n It also allows Agile teams to change the implementation without losing the architectural intent.<\/p>\n Product-centricity is a major feature of Open Agile Architecture.<\/p>\n Instead of creating temporary projects that disappear after delivery, O-AA describes product-centric organizations using cross-functional teams responsible for developing and operating products and services.<\/p>\n Consider a company launching a:<\/p>\n Digital Wallet Product<\/strong><\/p>\n We could start with:<\/p>\n Now add the systems providing those capabilities.<\/p>\n And underneath them:<\/p>\n But we can go further.<\/p>\n The product also has ownership.<\/p>\n The team might include:<\/p>\n The architecture therefore becomes much more than an application diagram.<\/p>\n It captures:<\/p>\n Product<\/strong><\/p>\n \u2193<\/p>\n Customer Services<\/strong><\/p>\n \u2193<\/p>\n Business Processes<\/strong><\/p>\n \u2193<\/p>\n Applications<\/strong><\/p>\n \u2193<\/p>\n Technology<\/strong><\/p>\n \u2193<\/p>\n Team Ownership<\/strong><\/p>\n Imagine the Ledger Service<\/strong> will be changed.<\/p>\n Using an architecture repository, we can ask:<\/p>\n That is architectural impact analysis.<\/p>\n This model makes the product the architectural center of gravity<\/strong>, rather than treating systems as independent IT assets.<\/p>\n Architecture therefore becomes directly useful to autonomous product teams.<\/p>\n Another useful application of ArchiMate in an Agile enterprise is connecting value delivery to technology dependencies<\/strong>.<\/p>\n Consider a payment company.<\/p>\n The customer wants one thing:<\/p>\n Pay a merchant successfully.<\/p><\/blockquote>\n We could model a value stream:<\/p>\n Now map capabilities to stages.<\/p>\n Next, connect the applications.<\/p>\n Suppose architecture analysis identifies the following:<\/p>\n Suddenly the architecture tells a story.<\/p>\n The majority of transaction latency is associated with:<\/p>\n Fraud Assessment<\/strong><\/p>\n And that stage depends on:<\/p>\n Fraud Engine<\/strong><\/p>\n The architecture team can therefore investigate that part of the architecture rather than launching a broad “payment performance improvement project”.<\/p>\n Perhaps the fraud service is synchronous when part of its workload could become asynchronous.<\/p>\n Or the problem might be:<\/p>\n Agile Architecture should help teams make better and faster decisions.<\/p>\n The Open Group’s Agile Architecture modelling guidance specifically emphasizes using architecture models iteratively to support communication, prioritization, collaboration, and the management of architectural and technical debt.<\/p>\n Instead of producing architecture merely as documentation, this model becomes an instrument for improving value flow<\/strong>.<\/p>\n Security architecture is frequently handled badly in Agile environments.<\/p>\n One team develops the application.<\/p>\n Another team performs security review shortly before release.<\/p>\n Problems are discovered.<\/p>\n The release is delayed.<\/p>\n O-AA explicitly includes Agile Security Architecture<\/strong> among its practitioner competencies.<\/p>\n ArchiMate gives security architects a useful mechanism for making security requirements traceable through the architecture.<\/p>\n Consider an Internet Banking platform.<\/p>\n Start with the business concern.<\/p>\n Now connect the requirement to the architecture.<\/p>\n Additional requirements could include:<\/p>\n And:<\/p>\n Now the security architect can trace:<\/p>\n Risk \u2192 Requirement \u2192 Control \u2192 Application \u2192 Infrastructure<\/strong><\/p>\n Suppose the existing system does not satisfy these requirements.<\/p>\n We can model the transformation.<\/p>\n This model can evolve alongside the product backlog.<\/p>\n Individual deliverables can become epics or features for Agile teams.<\/p>\n Security is no longer represented by a document attached after architecture has been designed.<\/p>\n It becomes part of the architecture itself.<\/p>\n As the product changes, architects can immediately determine:<\/p>\n That supports continuous security architecture rather than stage-gated security review.<\/p>\n These examples demonstrate four particularly valuable ways ArchiMate can complement an O-AA architecture practice.<\/p>\n The important point is that these are not four disconnected diagrams<\/strong>.<\/p>\n They can exist inside one architecture model.<\/p>\n For example:<\/p>\n That traceability is one of the biggest benefits of Enterprise Architecture modelling.<\/p>\n If you are just starting, resist the temptation to model your entire organization.<\/p>\n Choose one problem.<\/p>\n For example:<\/p>\n “How does our online payment service work?”<\/p><\/blockquote>\n Start with approximately ten elements.<\/p>\n
\nWhat is the relationship between ArchiMate and O-AA?<\/h1>\n
\n
\nWhy use ArchiMate instead of ordinary boxes and arrows?<\/h1>\n
\n
\n
\nThe easiest way to understand ArchiMate<\/h1>\n
\nThe main ArchiMate domains<\/h1>\n
1. Motivation<\/h2>\n
\n
\n2. Strategy<\/h1>\n
\n
\n
\n3. Business Layer<\/h1>\n
\n
\n4. Application Layer<\/h1>\n
\n
\n5. Technology Layer<\/h1>\n
\n
\n6. Implementation and Migration<\/h1>\n
\n
\nStructure, Behavior, and Information<\/h1>\n
Active Structure \u2014 WHO or WHAT performs something<\/h2>\n
\n
Behavior \u2014 WHAT happens<\/h2>\n
\n
Passive Structure \u2014 WHAT is acted upon<\/h2>\n
\n
\nRelationships: The grammar of ArchiMate<\/h1>\n
Composition<\/h2>\n
\n
\nAssignment<\/h2>\n
\nRealization<\/h2>\n
\nServing<\/h2>\n
\nAccess<\/h2>\n
\nFlow<\/h2>\n
\nTriggering<\/h2>\n
\nViews and Viewpoints: Don’t show everything at once<\/h1>\n
Executive view<\/h3>\n
Product Owner view<\/h3>\n
Solution Architect view<\/h3>\n
Infrastructure Architect view<\/h3>\n
Security Architect view<\/h3>\n
\nNow let’s use ArchiMate with O-AA<\/h1>\n
[Element Type: Element Name]<\/code><\/p>\n
\nExample 1 \u2014 Modelling Architecture Around a Customer Outcome<\/h1>\n
Scenario<\/h2>\n
Step 1 \u2014 Model the motivation<\/h3>\n
[Stakeholder: Prospective Customer]\r\n\r\n \u2193\r\n\r\n[Driver: Simple Digital Banking Experience]\r\n\r\n \u2193\r\n\r\n[Goal: Reduce Account Opening Friction]\r\n\r\n \u2193\r\n\r\n[Outcome: Account Opened in Under 5 Minutes]\r\n<\/code><\/pre>\nStep 2 \u2014 Identify the capability<\/h3>\n
[Outcome: Account Opened in Under 5 Minutes]\r\n\r\n \u2193\r\n\r\n[Capability: Digital Customer Onboarding]\r\n<\/code><\/pre>\nStep 3 \u2014 Model the business journey<\/h3>\n
[Value Stream: Become a Customer]\r\n\r\n \u2502\r\n \u251c\u2500\u2500 Submit Details\r\n \u2502\r\n \u251c\u2500\u2500 Verify Identity\r\n \u2502\r\n \u251c\u2500\u2500 Perform Compliance Check\r\n \u2502\r\n \u2514\u2500\u2500 Activate Account\r\n<\/code><\/pre>\nStep 4 \u2014 Connect technology<\/h3>\n
[Business Process: Verify Customer Identity]\r\n\r\n \u2193 served by\r\n\r\n[Application Service: Identity Verification]\r\n\r\n \u2193 realized by\r\n\r\n[Application Component: Digital KYC Platform]\r\n\r\n \u2193 supported by\r\n\r\n[Technology Service: Container Runtime Platform]\r\n<\/code><\/pre>\nHow this supports O-AA<\/h2>\n
\nExample 2 \u2014 Modelling a Product-Centric Architecture<\/h1>\n
[Product: Digital Wallet]\r\n\r\n \u2502\r\n \u251c\u2500\u2500 Customer Registration Service\r\n \u251c\u2500\u2500 Wallet Management Service\r\n \u251c\u2500\u2500 P2P Transfer Service\r\n \u251c\u2500\u2500 Merchant Payment Service\r\n \u2514\u2500\u2500 Transaction History Service\r\n<\/code><\/pre>\n [Product]\r\n Digital Wallet\r\n \u2502\r\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\r\n \u2502 \u2502 \u2502\r\n \u25bc \u25bc \u25bc\r\n\r\n [Business [Business [Business\r\n Service] Service] Service]\r\n P2P Transfer Merchant Pay Wallet Mgmt\r\n\r\n \u2502 \u2502 \u2502\r\n \u25bc \u25bc \u25bc\r\n\r\n [Application Components]\r\n\r\n Wallet API\r\n Payment Engine\r\n Ledger Service\r\n Fraud Engine\r\n Notification Service\r\n<\/code><\/pre>\n [Technology Services]\r\n\r\n Kubernetes Platform\r\n API Gateway\r\n PostgreSQL Database\r\n Message Broker\r\n Identity Platform\r\n Observability Platform\r\n<\/code><\/pre>\n[Business Role: Digital Wallet Product Team]\r\n\r\n \u2193\r\n\r\n [Product: Digital Wallet]\r\n<\/code><\/pre>\nProduct Owner\r\nSoftware Engineers\r\nSecurity Engineer\r\nSRE \/ Operations Engineer\r\nUX Designer\r\nData Analyst\r\n<\/code><\/pre>\nWhy this matters<\/h2>\n
\n
How this supports O-AA<\/h2>\n
\nExample 3 \u2014 Modelling a Value Stream to Find Architectural Bottlenecks<\/h1>\n
[Value Stream: Complete Merchant Payment]\r\n\r\n \u2502\r\n \u251c\u2500\u2500 1. Capture Payment\r\n \u2502\r\n \u251c\u2500\u2500 2. Authenticate Customer\r\n \u2502\r\n \u251c\u2500\u2500 3. Assess Fraud Risk\r\n \u2502\r\n \u251c\u2500\u2500 4. Authorize Payment\r\n \u2502\r\n \u251c\u2500\u2500 5. Post Transaction\r\n \u2502\r\n \u2514\u2500\u2500 6. Notify Customer\r\n<\/code><\/pre>\nCapture Payment\r\n \u2193\r\n[Capability: Payment Acceptance]\r\n\r\nAuthenticate Customer\r\n \u2193\r\n[Capability: Digital Identity]\r\n\r\nAssess Fraud Risk\r\n \u2193\r\n[Capability: Fraud Management]\r\n\r\nAuthorize Payment\r\n \u2193\r\n[Capability: Payment Processing]\r\n\r\nPost Transaction\r\n \u2193\r\n[Capability: Financial Ledger Management]\r\n\r\nNotify Customer\r\n \u2193\r\n[Capability: Customer Communications]\r\n<\/code><\/pre>\nPayment Acceptance\r\n \u2193\r\nPayment Gateway\r\n\r\nDigital Identity\r\n \u2193\r\nIdentity Service\r\n\r\nFraud Management\r\n \u2193\r\nFraud Engine\r\n\r\nPayment Processing\r\n \u2193\r\nPayment Switch\r\n\r\nLedger Management\r\n \u2193\r\nCore Ledger\r\n\r\nCustomer Communications\r\n \u2193\r\nNotification Service\r\n<\/code><\/pre>\nPayment Gateway 100 ms\r\nIdentity Service 150 ms\r\nFraud Engine 1800 ms\r\nPayment Switch 120 ms\r\nLedger 200 ms\r\nNotification 50 ms\r\n<\/code><\/pre>\n\n
How this supports O-AA<\/h2>\n
\nExample 4 \u2014 Modelling Security as Part of Agile Architecture<\/h1>\n
[Stakeholder: CISO]\r\n\r\n \u2193\r\n\r\n[Driver: Account Takeover Risk]\r\n\r\n \u2193\r\n\r\n[Goal: Protect Privileged Administrative Access]\r\n\r\n \u2193\r\n\r\n[Requirement: Privileged Access Requires MFA]\r\n<\/code><\/pre>\n[Requirement]\r\nPrivileged Access Requires MFA\r\n\r\n \u2193\r\n\r\n[Application Service]\r\nAdministrator Authentication\r\n\r\n \u2193\r\n\r\n[Application Component]\r\nIdentity and Access Management Platform\r\n\r\n \u2193\r\n\r\n[Technology Service]\r\nMulti-Factor Authentication Service\r\n<\/code><\/pre>\n[Requirement]\r\nAll administrative activity must be auditable\r\n\r\n \u2193\r\n\r\n[Application Service]\r\nSecurity Audit Logging\r\n\r\n \u2193\r\n\r\n[Application Component]\r\nCentral Logging Platform\r\n<\/code><\/pre>\n[Requirement]\r\nAdministrative interfaces must not be Internet accessible\r\n\r\n \u2193\r\n\r\n[Technology Service]\r\nPrivate Administrative Network\r\n\r\n \u2193\r\n\r\n[Node]\r\nManagement VPC\r\n<\/code><\/pre>\n[Plateau]\r\nCurrent Internet Banking Platform\r\n\r\n \u2193\r\n\r\n[Gap]\r\nPrivileged authentication lacks MFA\r\n\r\n \u2193\r\n\r\n[Work Package]\r\nPrivileged Access Modernization\r\n\r\n \u2193\r\n\r\n[Deliverables]\r\nIAM Integration\r\nMFA Integration\r\nCentral Audit Logging\r\nPrivate Management Network\r\n\r\n \u2193\r\n\r\n[Plateau]\r\nHardened Internet Banking Platform\r\n<\/code><\/pre>\nHow this supports O-AA<\/h2>\n
\n
\nPutting the four examples together<\/h1>\n
\n\n
\n \nO-AA concern<\/th>\n ArchiMate can model<\/th>\n Example<\/th>\n<\/tr>\n<\/thead>\n \n Outcome-based architecture<\/td>\n Drivers, goals, outcomes, capabilities<\/td>\n Digital onboarding<\/td>\n<\/tr>\n \n Product-centric architecture<\/td>\n Products, services, components, teams<\/td>\n Digital wallet<\/td>\n<\/tr>\n \n Agile value delivery<\/td>\n Value streams, capabilities, processes, applications<\/td>\n Merchant payments<\/td>\n<\/tr>\n \n Agile Security Architecture<\/td>\n Drivers, requirements, applications, technology and migration<\/td>\n Internet banking security<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Customer Outcome\r\n \u2193\r\nCapability\r\n \u2193\r\nValue Stream\r\n \u2193\r\nProduct\r\n \u2193\r\nBusiness Service\r\n \u2193\r\nBusiness Process\r\n \u2193\r\nApplication Service\r\n \u2193\r\nApplication Component\r\n \u2193\r\nTechnology Service\r\n \u2193\r\nInfrastructure\r\n<\/code><\/pre>\n
\nYour first ArchiMate model<\/h1>\n
Step 1 \u2014 Define the outcome<\/h3>\n