The presentation walks through:
- Target State Architecture Examples
- Target State Architecture Diagrams
- A Data-Driven Approach to Architecture
BEC have incorporated collaborative Enterprise Architecture into their strategy, bringing both IT and Business teams together whilst migrating from isolated modeling (e.g. PowerPoint, Visio) to a more data-driven approach. Working towards forming a target state architecture to harmonize future business requirements and to support operational goals.
This webinar was a part of Avolution’s Enterprise Architecture Summit 2023
Q&A
Q: As mentioned in the presentation, BEC already has Sparx in their setup. Why didn’t they use Sparx? What was the purpose of integrating ABACUS with SparxEA? (Data-Driven EA)
A: Yes we do have Sparx EA, but unfortunately not used much. There are parts of the organization that use it though. Our Business Process department (BPD) are using it to map Business Processes. But they still have the same issue as we in EA have, thus introducing ABACUS. And that is the Datamodel in Sparx EA does not support Different Architecture comparisons (ASIS, TOBE, Transition Architectures and Different Scenarios) as ABACUS does. In ABACUS you can very quickly compare all architectures as all components, attributes and relationships via Matrix, Catalogues and/or Diagrams. We have had a PoC with Avolution Software and our BPD, Based on BPMN notation, for them to get feel for ABACUS. I expect we will go that way at some point. In our future plans we will import Business Processes, as they are quite important for our goal to map and document Value Streams, Value Stages and Customer Journeys.
Q: Could you mention any numbers on business impact and results from Architecture effort?
As we have just started we don’t have specific numbers yet. But from what we can see is that the turn-around time for making the target architectures, consolidating them into one, has been much quicker. Reason for that is, the EAs doing the consolidation and validation, has a standard viewpoint to look at instead of multiple different ways of visualizing the different domains Target Architectures (TA). Also when our baselining is done (Where all Domains have created and verified their TA), we will in the future only create TAs, where there will be changes.
Q: Is the target state architecture essentially a copy of As-Is but with a few target changes? Or is the target state architecture strictly the changes/new components and relationships that are merged into As-Is?
The Consolidated Target architecture starts out as a copy of AS-IS, yes. The Domain architectures are subsets of the Consolidated Target Architecture (TA). When all the Domains have created their Target Architectures, they will be merged/Synced back to this and locked. We then track the gaps between the AS-IS and the Consolidated Target Architecture.
For example with the lifecycles of the Work Packages needed in the transitions towards the TA. So you can say, nothing is directly merged into the AS-IS architecture, but during the transition, it should look more and more like the consolidated TA.
Q: Please describe more how ArchiMate is used and whether this lead to duplicative work putting the same work in ABACUS
It should not lead to duplicate work, but there are areas where the different domains need a higher level of details, where we have chosen not to incorporate the components yet. Example could be infrastructure details like servers and network domain components which would be in the CMDB domain. We try to keep our abstraction level on the the architectural components, not infrastructure CI area. Our application mapping should start with ABACUS but continued in the CMDB if more details are needed.
Q: Have you applied permissions on the architectures to hide some projects for certain users?
Yes. Our Test Architectures we use for development of Models, Components, Relations & Constraints, Viewpoints and scripts are only accessible for Studio Admins. The User groups in ABACUS are mapped to our roles within BEC, and determines CRUD on an architectural level. Special Scenarios that need to be hidden because of sensitivity in the organization, need special groups to handle that. We also do some permission handling in the attribute scope, fx financial data needs specific groups to either Create, Read, Update or Delete. This was mostly based on ABACUS Studio, but in ABACUS Enterprise, we also control permission to view specific Dashboards.