Aggregated enterprise architecture wisdom
You’re all familiar with the knuckle-dragging pre-human to bipedal homo sapiens series of silhouettes that looks like it first appeared in National Geographic (anyone remember?). But this time I’m using them to illustrate some of the major po…
You’re all familiar with the knuckle-dragging pre-human to bipedal homo sapiens series of silhouettes that looks like it first appeared in National Geographic (anyone remember?). But this time I’m using them to illustrate some of the major po…
You’re all familiar with the knuckle-dragging pre-human to bipedal homo sapiens series of silhouettes that looks like it first appeared in National Geographic (anyone remember?). But this time I’m using them to illustrate some of the major points on the upward curve of software evolution.
And while neither human evolution nor software advances in correctness are as linear or as easily charted as the graphic suggests there is a similarity between them where highlights from a particular tree become visible from a single point in time, like now and to me.
Starting with Structured Programming – this was a breakthrough in code maintainability where similar logic or logic related to similar data was modularized for easier understandability. Without such an approach if/then/else clauses spanned many pages, making a code base nearly impossible to debug in a timely manner much less to hand off to another developer.
Objects overcame the division between separating code by logic or by data by allowing the developer to combine them both into an object, a single entity.
While this was a revolution to those in the craft of writing code it only helped those writing code to understand their world better and outsiders were not usually part of the arrangement of objects, class diagrams and activity diagrams notwithstanding.
Services and processes were the first entities (in this tree) to be of concern outside the development community. They could be thought of as directly supporting the business. They could be socialized and discussed by subject matter experts and process owners. Although services could be placed in repositories and called by other services and SOAP vs. REST could be argued by the technology community these were sub-plots to what was going on. And what was going on? Software usage was mushrooming and becoming a management problem that wouldn’t go away.
In other words, software was experiencing catastrophic success.
In the late 90s and early 2000s the DoD came upon the concept of capability. Each branch seemed to have its own take on how to utilize the concept and in the current DoDAF capabilities have their place in the DoDAF meta-model.
I’m here to tell you that the story doesn’t stop there. While having a meta-model is critical to keeping your feet on the ground there’s a lot more to capabilities than that.
In short, we at SenseAgility Group, are offering a Capability Based Business Architecture course that draws its inspiration from such things as IEEE 1471, MIT Sloan’s Business Operating Model, UML, BPMN, Archimate, & TOGAF. This means that we provide, through a succinct capability lens, a way to connect architecture with business architecture on a cost and value basis. Not only that but we can connect process, organization and risk/security issues in the same way.
This allows management at any level to organize software and invest in it according to their strategic plan or even to develop a strategic plan using capability based analysis. That last idea, btw, is what the Capability Portfolio is all about.
DPT