Architecture In Motion is a powerful platform that streamlines the management of design artefacts across Enterprise Architecture, Solution Architecture, Program Architecture and provides a comprehensive Project Portfolio View.
With four distinct loops – Enterprise, Project, Component, and Portfolio – it enables increased openness and transparency, reduces risk and cost, and helps drive the improvement of Business and IT across the Enterprise.
Whether you’re creating, updating and reviewing the whole of Enterprise views, planning and delivering projects, curating and enhancing reusable Architecture building blocks, or analyzing and improving overall IT portfolio investment health, Architecture In Motion has you covered
- Enterprise loop – creating, updating, and reviewing the whole of Enterprise views to support developing a strategic investment plan.
- Project loop – planning, designing, and delivering projects
- Component loop – curating and enhancing reusable Architecture building blocks
- Portfolio loop – analysing and improving overall IT portfolio investment health
These loops run in parallel and have a ramp-up and business-as-usual stages.
This page overviews how to ramp up and run each of these loops.
Each of these loops intersect in various ways, so it is essential to understand how they work together to support the entire Business and IT investment lifecycle.
The purpose of the Enterprise Loop is to develop, share, and update strategic investment plans.
Example views developed might cover your organisation structure, capabilities, and applications used, and then overlay these views with tags to enable project roadmap planning at a strategic level.
When creating Enterprise views, you can make any hierarchy of ArchiMate elements, add tags, and apply shading to help generate insights.
Where you include the Work Packages element (projects) in a diagram, you can define the start date and end date properties to edit a high-level investment roadmap view. See Example 2 below
All diagrams can be extracted as an image of SVG for you to copy into other documents.
Example 1. A view of the organisation structure and the applications used. Several tags are shown, incl. Status, Domain, and Criticality.
Example 2. A list of proposed projects and their project type – tactical or strategic.
The Project Loop is fundamentally about ensuring that the latest versions of all project architecture models are uploaded into AIM.
These architecture models can be at different stages of development, from concept through to As-Designed (aka Available for Construction) and then As-Built.
This is one key area in which AIM differs from typical architecture repositories in that AIM has been designed to allow for the upload of project architectures.
Uploading project architectures is a necessary discipline to help remove the ‘fog of war’ and allows discovery and conversations to occur that otherwise would not happen.
Having the ability to surf through all of your business’ project architectures enables discovery and insights to occur organically, enabling assurance outcomes to be achieved more easily than the ‘too little, too late’ governance experience.
Once you have agreed as an organisation to ensure that all project models are kept up-to-date, the activities you should perform per project are:
- Component Reuse – Make sure that projects go through a checkpoint where they select which Component to reuse. AIM allows you to import models fragments from your Components digitally. The first step is an assurance check on what reusable components a project will and will not use.
- Project Tagging – Tag your projects with agreed tags, e.g. project type, domain, owner, etc., and any tag you can use to generate insights across the entire portfolio of projects using AIM’s Project Explorer.
- View Tagging – Tag views within your project using agree on tags, e.g. type = Motivation, stage = Current State or Future State.
- Stories – Create project stories to help explain different project architecture models. Stories can be anything you might otherwise explain in a meeting or build into a PowerPoint presentation. By developing stories, you are allowing the people in your Enterprise to self-discover and understand your project so they can provide feedback.
- Modelling Consistency – Apply rule checking to project architectures to improve modelling consistency, being whatever your Enterprise defines this to be. The AIM rules engine allows you to define custom rules much like you might include in an Enterprise discussion about meta-models and also apply machine learning to learn from any models you select as good examples. Consistent models make it easier for people to understand the model, which is a precondition for them to provide feedback.
- Scope Validation – Check that projects define the work packages to be delivered. Failure to do this often results in incomplete identification of work to be performed, and then time/cost blowouts.
When the project has reached an As-Designed (the design is complete, but you haven’t started building) or As-Built (this is how we changed the design during the build) stage, then you should harvest any reusable elements from it to either create new reusable Components, or update any existing Component designs.
An analogy to why you would want to update Components is the same as for other package manager tools, e.g. Maven, Node, Apt, NuGet. This is that the Project should seek to mostly glue together reusable components.
Architects often do a great job defining a target state but leave details out when explaining how the target architecture will be delivered.
AIM can extract the Work Packages and Deliverables from your model into a hierarchical view to make it easy to see how the project team are planning to deliver and if a robust work breakdown structure (WBS) has been defined.
If not, you risk not having identified the time and cost to deliver the target architecture.
The WBS typically represents the direct costs to deliver the target architecture and should be combined with indirect costs in collaboration with a project manager.
The Component Loop is fundamentally about driving the continuous improvement of reusable Architecture building blocks over time.
The main principle behind “What is a component?” is the same as for Object-Oriented programming.
A Component should have high-cohesion and low-couping.
- High-cohesion means that the component does 1 thing well.
- Low-coupling means that the way in which you use the component is well-defined, and a change to the component should not require changes to consumers of that component.
Candidates for ‘Components’ in an Enterprise are:
- Your main application platforms, e.g. Finance, Customer, Marketing, Ordering, Supply Chain. You might even break these into sub-components.
- Your main technology platforms, e.g. integration, messaging.
- You business capabilities and processes, which can serve as a reference for project architectures.
Your goal when creating a Component is to make it easy for people in your business to understand what is available for reuse and how to use it, not necessarily how it works.
As such, you would author Component architecture models in a way that both explained their inner workings but also provided views that show the interface to the component. The interface could be a user interface and/or API of some kind, e.g. files, REST, XML, etc.
Just like Projects, you can also add tags to categorise components, and create stories to further enable self-discovery by people in your business.
Projects and products are means to an end, serving to improve the state of the Enterprise.
The traditional approach to Enterprise portfolio management often lacks depth, providing only a limited view of projects with limited information.
To gain a comprehensive understanding, it’s essential to have the ability to view all projects, filter and group based on shared tags, search across projects, and delve into project architecture details as needed.
This provides visibility into the purpose of each project, alignment to strategic goals, and the overall success of the Enterprise portfolio in delivering desired outcomes.
Some typical portfolio-level questions are:
- How many projects are planned and in flight?
- Do the projects introduce any duplication or fragmentation?
- Do the projects align with strategic goals?
- How much technical debt is being created or remediated?
- Which Architects are working on which projects?
- Who are the project sponsors?
- Do all of the projects have a well-defined and agreed-on problem space?
- What are the critical decisions being made by projects?
- What components are being reused by projects?
The above are all questions that can be answered if you ensure that all project architectures are loaded into AIM, and that you consistently tag projects to enable such analysis.
AIM’s Stories feature further enhances the openness and transparency of Architecture content.
These narratives provide a visual representation of Architecture models with color-coding to highlight important elements.
Allowing your staff to self-discover and view these stories enables easier understanding of Architecture models and their implications.
Stories can cover specific topics such as the use of reusable IT components, security aspects of projects, implementation details, information exchange, technical debt, work packages, and prioritized Enterprise capabilities.
By utilizing Stories effectively across projects and components, you can reap benefits such as reduced IP loss with staff turnover, reduced need for meetings, and faster and improved decision-making
Add tags to projects, components, views, and stories
User-defined tags can be added to several elements within AIM – projects, components, views, and stories
Consistently tagging items in AIM helps improve discoverability and portfolio analysis.
Some suggestions for tagging might include:
- Projects – Use the following tag types: Lifecycle/funding stage, Domain, Endorsement status, Architect, Sponsor
- Components – Use the following tag types: Domain, Owner
- Stories – Use a ‘Type’ tag with one of the following values: Technical Debt, Project Changes, Security
- Views – Use a ‘Type’ tag that might have a value of Motivation, Business, Application, Technology, Information, Implementation, or Layered.
You may use any tag conventions. However, the above examples help you define an approach that works best for you.