**DRAFT**
The team I work with at Pivotal is responsible for implementing Pivotal Cloud Foundry (PCF). Since our platform turns the traditional approach to governance upside down, our customers often ask for our advice as to how those processes change when operating under a cloud model. The temptation is to throw the baby out with the bathwater, as many see centralized governance and agile as an impedance mismatch. While I generally agree with that sentiment, it does not help our customers who require certain aspects of these processes to remain compliant (SOX, etc). This is the first in a series of articles outlining the shift in perspective required to successfully adopt microservices and the cloud approach in a traditional enterprise, specifically with a focus on applications.
I began my career in a group where I built tooling around a central Configuration Management Database (CMDB). I have also played the role of enterprise architect in a large enterprise. As a result, I have strong opinions about not only how to define applications, but around the processes which are an ancillary but also essential area of consideration when defining them. The core tenet of ITIL and enterprise architecture is to impose centralized governance, and is therefore diametrically opposed to agile and DevOps as they embrace autonomy and trust for each individual team. Microservices pushes even further against decentralized governance and disrupts down to the data layer; microservices may maintain copies of data liberally, and the notion of a master data model is considered abhorrent in this architecture.
However, the need to maintain a centralized system of record, separation of duties, and the ability to produce all of the artifacts necessary to pass an audit do not vanish just because of autonomy. The two can and should co-exist. The caveat is that automation drives most, if not all, of the necessary information in a central CMDB. Continuous integration and delivery (CI/CD) pipelines are usually built to cover all of these bases; who made what changes, who authorized those changes to go to prod, when those changes went to prod, and any necessary configuration item updates based on those changes can all be driven by the pipeline.
Surprisingly, the question of “What is an app?” comes up with nearly all of my customers. An app, simply put, should be defined as a set of deployable resources which encapsulates a business process or opportunity. Characteristics such as the domain model, outward facing interfaces, database schemas and datasources, how the business users of an app speak about their system, its boundaries, and how other apps interact with their app all define an app. In DDD, we call this a bounded context.
To figure out how to effectively define app CIs, it begs the question as to how this information will be used. All of the other ITIL based processes ebb and flow from this CI definition, its attributes and relationships. Each of the downstream processes will also produce data related to that application. For example, Incident Management will need to know how to associate incidents with a related set of CIs, and Change and Release Management have their own specific needs.
Over time, most large enterprises struggle to keep an application well-defined as consumers ask for more from those apps and the domain model grows well outside of the original intent. The guidance provided in DDD literature helps us to identify boundaries in systems which have grown into a big ball of mud (accidental architecture) and lends the necessary tools to redefine those boundaries and ultimately to refactor those monoliths into microservices.
In order to really understand these abstract concepts, it’s best to exercise them. Identify an app which has succumbed to the big ball of mud scenario and which could benefit from being decomposed into microservices. Each of these microservices becomes its own app, by definition. The relationships these apps have with one another are derived from context mapping exercises. All of this is well explained in Vaughn Vernon’s Domain Driven Design, and I encourage my customers to spend time reading his work.
