Part 2: Deliverables, Artifacts & Architectural Building Blocks
In Part 1 gave an overview of TOGAF ADM, ArchiMate & the BCLC / SDLC and how they integrate with one another.
Deliverables, Artifacts & Architectural Building Blocks (ABB’s)
It is key to understand the concept of architectural building blocks and how they relate to artefacts and how artefacts are then incorporated into deliverables.
One could view the architectural building blocks as those objects that you want to manage in your repository as “master” objects. With other words those objects that belong to the different architectural domain areas that needs to be managed. See sample of architectural building blocks per domain area that needs to be managed:
.jpg)
Architectural building blocks are then used to create models and matrices or artefacts. See illustration of typical artefacts and relationship to architectural building blocks below (sample):
.jpg)
The defined artefacts are then included in deliverables i.e. initial product requirement specifications (PRS v0.1), conceptual solution architecture document (CSAD), detail product requirement specifications (PRS v1.0), logical solution architecture document (LSAD), product design specification (PDS). See key artefacts that are included in the initial product requirement specification (PRS v0.1) as per the iBAS solution (integrated business architecture solution). The PDS (as well as all the other SDLC specifications / documents) are generated directly from the ARIS repository using the iBAS report script.
.jpg)
Here is a graphical representation of the PRS and the associated artefacts:
.jpg)
In part 3 I will explain the different options when executing the SDLC using waterfall vs. agile.
Getting down to being pragmatic - how do you represent current and target architectures in ARIS? For example, is it valid in your view to have the Master model/object as the current architecture, and hold a variant model/object as the target architecture?
We already use variant management for distinguishing between our standard designs and our permitted variant designs (examples: localised process deployed as variant process flow of the standard process flow; product/service specific process flows)
So we're already overladen with the mentally taxing variant management. Are there alternative ways of holding target architectures alongside current architectures in the same database?
Or should I hold current in one db, target in another, then use MashZone (or other?) to compare the two, report differences, show the progress from current to target?
Or do I lose the argument for ARIS and we move to something else?
Gartner has a good article on this "Develop the Enterprise Solution Architecture" and summarized below. In short you have to identify your core master building blocks across the business layer, application layer, data layer and technology layer and tag them as master objects i.e. BA master = business architecture master. You then build master enterprise solution architecture views using the master building blocks and tag them as master solution architecture building blocks and version them i.e. ESA for processing claims v1.0. Any solution architecture that is then developed (also using master building blocks) per project can then be compared with the master ESA using the ARIS compare functionality.
