Data & Analytics Capabilities
Do you already think in capabilities or directly jump into the solution?
When I first worked with a Data & Analytics Capabilities Model I was impressed but also overwhelmed, too. Capability models can help to broaden your architectural thinking if you are open to use them.
What even is a capability? Due to The Open Group:
“…, a capability is defined as “an ability to do something”.“
In my practice I work with different kinds of capability models. In my company we have a general Data & Analytics Capability Model which works in most of the cases and can be expanded on demand.
For some domains like metadata management (data catalog) or others we have Level 3 models helpful in certain situations. I have seen capability models from customers, but only if they have a larger Enterprise Architecture practice. But very few are really public available.
Currently I try the SAP Data & Analytics Capability Map:
I was part of the discussion with SAP, while this map was created as part of the SAP Data and Analytics Advisory Methodology. Like here many aspects had to be considered like:
First - do you want to have a practical on-pager, showing everyone immediately or having e. g. a multi-slide framework you need to work through each time.
Considering existing frameworks like the SAP Integration Solution Advisory Methodology (ISA-M) which has to be known and available to integrate it fully. As here for Data Integration it was already part of the ISA-M.
The breath, depth and levels you provide - typically you have at least a general category (Level 1) like Data Management, Data Integration, … and a Level 2 more detailed capability perspective. We all new that behind such a capability like Data Replication or Data Life Cycle Management there are several more features to be considered.
A common understanding of terms and capabilities - as this area is heavily blurred by vendors pushing terms like Data Product or Data Marketplace, being so specific or fuzzy, that the meaning needs to be specified in the context of your activity.
A data architect translates between the problem domain and the solution domain. But to understand the problem you shouldn’t start with the solution a vendor already gives to you. This is where a capability model could help.
SAP recommends one of the following approaches to work out your capability mapping:
Architect-Led Approach: The (enterprise) architect identifies the relevant capabilities based on the requirements discussed in Phase II. This capability map is then validated with the relevant stakeholders.
Stakeholder-Led Approach: Gather relevant stakeholders to discuss and define the required capabilities. Use the Data & Analytics Capability Model domains as a reference to map these capabilities.
Typically I would rather start with the first approach, as this is often much faster and you can build on it. This needs several workshops in advance with stakeholders and data teams. In the second approach the stakeholders get a much deeper understanding of the capabilities and you will possibly have a different discussion. So both have their advantages and disadvantages to consider.
The final goal is, to come from problem to solution, map the right solutions to the target architecture, based on the necessary capabilities and priorities, like in this example. Often it can make sense creating first some target architecture variants.
Often on the other side you can’t start on a green field. You have to consider existing solutions and possibly only single components will be new or you consolidate existing solutions.
In the case of SAP, they also support the process with available reference architectures, what is naturally rather focused on SAP technology:
If you are experienced in designing and discussion data architectures, like knowing just because a system can fulfill the capability, there are more things to be considered and not covered through the capability model:
User Experience
Integration into the overall IT landscape
Costs
Vendor roadmap
Stability and Trust
Support model
…
Often a software selection process follows to find the right component.
If you are interested in SAP’s approach I recommend to start at Alexander Bange’s (creator of this methodology) latest blog.
For an Enterprise Architecture perspective, having a look at the TOGAF Business Capability site could be interesting.
During my discussion on LinkedIn about this article, the TOGAF Information Architecture: Business Intelligence & Analytics came up. I recommend to have an additional look there.
How do you use similar capability maps or models in your work? What works well for you? Do you know other public available examples?