I’ve been thinking about the different services, policies and functions that support the delivery of applications to individual lines of business. Many of the organisations seem to struggle with this more than anything else in moving toward cloud adoption. As I’m often found saying “the technology can pretty much be made to do anything, the difficulty comes in first knowing what you want to do and then how you want to manage that”.
Ontology is defined as “a set of concepts and categories in a subject area or domain that shows their properties and the relations between them”. This nicely describes what I’ve attempted to do for line of business applications and where they are delivered be that as SaaS, PaaS, Heritage or Modern Apps.
For the purposes of this article SaaS apps are those that are delivered from a cloud by the vendor, PaaS is developed by the IT department using cloud technologies, Heritage is defining the existing application estate and Modern Apps are developed by the IT department using technologies such as containers delivered on premises or in the cloud.
To map these I’m going to use Wardley Maps. These are used widely in the sector I work in and partly using this method is to increase my familiarity with the concept and method, although as described on the wikipedia page, the method as devised can help me look at the application ontology.
“Each component in a Wardley map is classified by the value it has to the customer or user and by the maturity of that component, ranging from custom-made to commodity. Components are drawn as nodes on a graph with value on the y-axis and commodity on the x-axis. A custom-made component with no direct value to the user would sit at the bottom-left of such a graph while a commodity component with high direct value to the user would sit at the top-right of such a graph”
There is criteria to help plot the nodes on the map, that help guide placement for what should be considered as in genesis, customer built, product (rent) or a commodity.
The above table does a great job of explaining that. Although I would suggest that to understand a little better, you divert for a second and read this twitter thread, where Simon Wardley is to be found having a conversation with ‘X’.
The goal? Conversation. Each of these maps is subjective to my point of view and are by no means exhaustive. Nothing below could be considered ‘right’ or ‘wrong’, it’s opinion. If you like the technique I recommend you explore Simon Wardley’s own posts on mapping or the imaginatively named wardleypedia.
Below we have a map that describes the concepts, categories, services, policies and functions that go into delivering and supporting a SaaS application from the perspective of the line of business.
The SaaS app itself is a commodity and presumably delivers high value to the line of business otherwise it wouldn’t have been purchased, so that is placed in the top right. Next in the commodity/high value/visibility space is internet access, it is a commodity these days and it delivers the app to the line of business. Nodes of higher value but in a genesis phase include a cloud operating and zero trust model. The cloud operating model, it could be argued, allows the consumption of the SaaS application in the first place. The zero trust model secures access into the application and onward transmission of data assets etc. Both must evolve as the cloud landscape evolves, so are perhaps in a constant state of review and definition.
If I ran through every placement and node on the map for each of the applications, then this will rapidly turn into a book rather than a blog post. I’ve put some thought into the placement of nodes on this map. However, as mentioned earlier this placement is both subjective and situational to the organisation or line of business that is the subject of the map. What would the same map look like for your organisation or customers?
With the nodes plotted we can add lines to represent the interactions or ‘needs‘ between them, for example the SaaS app itself needs a Public cloud to run upon, so they are connected. I haven’t done this for these maps but movement can also be added to the map landscape to show evolution.
Below we have a map that describes the concepts, categories, services, policies and functions that go into delivering and supporting a PaaS application from the perspective of the line of business.
In the interests of brevity, I’ve jumped straight to the map with interactions between the various services.
It is interesting to observe the additional elements that are required to support what might be considered a cloud native PaaS application. It is possible I have overstated the complexity. Again, placement is both subjective and situational to the organisation or line of business that is the subject of the map. What would the same map look like for your organisation or customers?
Heritage applications, is another way to define the million and one applications that are not cloud ready, built on ageing technology perhaps, maybe considered as technical debt by the IT department. However, for what ever reason it’s critical to the Line of Business and cannot be just switched off.
Still of high value (whilst it works) and ostensibly not as complicated to implement and manage as the PaaS applications but does that come at a cost to the IT department or other organisational lines of service. If it does, how do you visualise that and make the argument for replacement? Financial information, if known can be added to the interaction lines. It is in this space that often arguments are made for direct lift and shift to Cloud IaaS, so how might that look?
When I think about the environments I’m aware of, is this a reduction in complexity and overhead or an exchange? Again, placement is both subjective and situational to the organisation or line of business that is the subject of the map. What would the same map look like for your organisation or customers?
Something that maybe more of a marketing term right now, for the purposes of the next map I’ve considered it to be new applications or services delivered and supported by a container.
How much of the complexity outlined above is removed by making containers easier to manage and by the evolution of the IT services to support this type of deployment? If applications start shipping from market places as containers that can be simply consumed will that add to the complexity? Will it require further evolution of private cloud resources to be delivered as commodities?
Complexity is everywhere, understanding and mapping that complexity will provide situational awareness, which can then be used to inform decisions, define reasons and measure success.
OK, snappy end quote….
“Define and where possible measure the value from relocating, refactoring, rearchitecting existing services to clouds, if you can’t do that then question why you are doing it…”
“…when considering new services, take a close look at the SaaS options and then still define and measure the value provided”