As I’ve been developing my engagement framework over the past few years, I have sometimes struggled to classify the exact phase in which certain activities take place. Or, more to the point, I have sometimes had difficulty contextualizing multiple different activities that may take place in the same phase. Although the framework has seemed very solid against watching several years of material in the practices of business analysis, project management, Agile and Scrum, and related disciplines, there seemed to be just a small thing missing, a bit of confusion I couldn’t quite resolve. A couple of posts where I wrestled with this are here and here.
Much of this particular confusion was lifted when a gentleman named Kieth Nolen, MBA, CBAP gave a presentation on business architecture to our weekly IIBA certification study group, as part of a professional series we did on different fields and activities business analysts need to be aware of. His presentation may be viewed at or downloaded from the Tampa IIBA chapter’s shared drive here. Look in the IIBATampaBayBABOKStudyGroup directory for the file named BABOKStudyGroup20220802.mp4 (which alas I cannot link to directly).
Mr. Nolen provided wealth of fascinating and useful information, including this table of perspectives to consider when analyzing or designing a system.
What really clicked for me was his description a tool called ArchiMate. It enforces certain (necessary) rules on the creations of diagrams expressing business architecture designs. The thing that made it pop, especially given what had preceded it, was its segregation of elements into three major layers. The tool refers to these as the business layer, the application layer, and the technology layer, as shown in the diagram below.
As the oodles of drawings elsewhere on my website will attest, I have spent many years expressing different aspects of architecture, design, and processes from different perspectives. I’ve always had an innate understanding of how to communicate what I needed to, but it’s always helpful to keep reading, listening, and learning so I find more and different takes on materials on interest. The longer you do something, assuming you’re on the right track, more and more of what you see should fit into your existing understanding. This makes it all the more interesting when you find something that actually appears to be new. Such findings can lead to important clarifications and breakthroughs, and I believe this happened with me.
I use slightly different language than Mr. Nolen or Archimate use, but it’s clear where the idea came from.
The standardized representation I’ve developed for my engagement and analysis framework is below. It has to be understood that this is a highly stylized and streamlined representation of what practitioners actually do when solving a problem for an internal or external customer.
This is meant to depict the iterative nature of the work within and between each phase at a high level. Implicit in this is that many activities can occur in each phase both in parallel (if several individuals or teams are doing similar things at the same time) and serially (if one individual or team performs several successive different tasks in the same phase.
Parallel activities may be depicted this way, by showing additional iterative cycles represented in depth:
Serial activities might be thought of in two ways, by showing additional iterative cycles represented horizontally:
The breakthrough can from expanding the representation in the vertical direction, as shown next:
This is where I’ve used slightly different language for the three layers. Where ArchiMate goes with business, application, and technology, I prefer what I feel are more general terms. Those are business, abstract, and implementation.
The business layer can include elements like business units or departments, people as individuals or in groups with similar responsibilities and permissions, and overall systemic responsibilities. The abstract layer includes descriptions of the processes, communication channels, data elements, activities, calculations, and decisions. Those can be determined logically through the discovery and data collection activities in the conceptual model phase, and also through various activities in the requirements, design, and implementation phases. Finally, the implementation layer (as differentiated from the implementation phase) describes all aspects of an implementation, in terms of the hardware, software, operating systems, governance and maintenance procedures and so on. While one is generally tempted to visualize IT systems first, foremost, and always in these situations, the considerations are meant to be more general than that. That is the primary reason for my using different language than what ArchiMate uses.
Moreover, I find that separating activities into layers in each phase can actually be done on an almost completely arbitrary way, and we aren’t limited to only the three layers listed. The specific insight provided by Mr. Nolen’s presentation has lead me to a more general conceptual understanding of how to proceed.
So how does this represent a breakthrough for my understanding and the interpretation of my framework? Let’s look at how activities may be broken down into layers within each phase.
- Intended Use (Problem Statement): This phase doesn’t immediately seem to break down into layers in an easy of obvious way. Problem statements and project charters are usually described at a high level with few items. These can be added to and clarified over time, as understanding increases through iteration between phases over the course of an engagement or program, but their general expression tends to brief. Additionally, a lot of the context may be subsumed within the very nature of the proposed solution approach.
- Conceptual Model: Discovery and data collection activities can be carried out to map and characterize existing (or new) systems along the line of the standard three layers. Other possibilities exist, however. One example I can think of was a two-part analysis we did of a complex, large scale business process, where we did a first pass of discovery and data collection to determine what and how much was going on and how long it took to complete an initial economic justification, and then a second pass of discovery and data collection to learn the details of each activity so an automated replacement system could be developed and deployed.
- Requirements: Several possible division exist here. Functional requirements describe what a system does (or will do) while non-functional requirements describe what a system is (or will be). Methodological requirements may govern how the engagement itself is to be run, how communications must occur, how things must be written, and so on. Requirements can exist for accuracy, for what must be considered in or out of scope, what hardware must be used, and more.
- Design: Designs can certainly cover the standard three layers, but I can think of multiple possible subdivisions within each layer. Particularly in the abstract (or application) layer, I look back to my days writing thermo-hydraulic models for nuclear power plant simulators, and see that the governing equations and the solution methods could be considered very distinct parts of the design. Multiple engineers could all agree that the governing equations are written correctly (those could actually be considered part of the conceptual model, by the way), but implement the actual performance of calculations in entirely different way. (Development of my framework has made it clear to me that, even though Westinghouse got good scores in an evaluation of its project management practices, lack of review and socialization of methods in this area was a major weakness of the organization.)
- Implementation: Beyond the three standard layers, the construction and deployment of a new system (or modifications of an existing system) can be seen as entirely separate subdivisions within at least the abstract and implementation layers. While I often write that I consider system maintenance and governance a subset of non-functional requirements, I also see the CI/CD or release train process for a system or capability to need as much effort, thought, care, and feeding as any other part of a developed and deployed system. This, this can be seen as its own layer through all of the phases (but especially this one), or an integral part of all other work. Either way, awareness of the need for this capability is crucial.
- Test (and Acceptance): Testing and acceptance can occur at so many places through every phase of the process that it almost should be left (per the forward and backward linkages required in the Requirements Traceability Matrix) to be driven by the linkages to the implementation items. Conversely, the different kinds of test can be considered separately, especially when it comes to the differences between verification (does the thing be built work as intended?) and validation (did we build the right thing to address the identified need, and is it sufficiently accurate?).
Coming to understand the possible vertical divisions within each phase makes my framework much more adaptable and powerful in my mind. I’m sure I will considering the subtleties and ramifications of these new insights for a long time to come.
I will also share that this insight has allowed me to put clearly into word the space in which I seek to work and help people. In the end, the main area I like to think in is in the middle or abstract (or application) layer. I can certainly support analysis and development of the business layer driven by that. Even more to the point, I’m not very interested in writing code or developing databases or mucking around with the details of deployment at this stage, and I’ve never been and expert at security but recognize its indispensability, but I’ve certainly done and learned enough to be able to work with the relevant specialists of every kind as needed.