Microservices on steroids, getting from just agile to business agile [part 2 of 2]

Summary

This is how you get Microservices on steroids; apply them in a Policy Oriented Architecture. Meaning that you need to put a policy handler in between a service's interface and its implementations. The reason why you want to do this, is because you want to provide agility to your business and not just have an IT department that's agile. Or in fact have an IT department at all for that matter.

It’s time for part 2 of a two part series on Microservices on steroids. I already had part of the post ready but today I was in a presentation on the topic of Continuous Delivery and Architecture and one of the aspects that came up was about ‘Product definition’ and I figured that I needed to put that into the mix as well.

The conclusion of the previous post (Microservices on steroids [1/2]) was that adopting a Microservices based architecture, which pretty much is an SOA the way it was meant to be, will only get you technical agility. As you can read in my post on Continuous Delivery not being something for the IT department only (The Continuous Delivery IT Team Fallacy), technical agility is only part of the story and in fact has limited value if you’re not targeting business agility.

But let’s first consider what Business Agility exactly means. It is in fact exactly what it literally means, agility of the business. The main difference with the ‘normal’ agility is that it allows the business to change its course rapidly without a direct need of involving IT to make this change. So without needing to worry about whether or not IT can handle these changes.

And it allows the business to respond to changes in its marketplace when and where necessary with the help of IT. So business agility is an extension of technical or IT agility.

An example of business agility is for example bank XYZ that issues debit cards to its customers age 16 and up. One of its competitors, bank ABC, is in a marketing campaign targeting teenagers and issues debit cards to 12 to 16 year olds when a letter of consent is signed by their parents or legal guardians. Our bank XYZ will lose out on a large customer segment when not also addressing these teenagers. So it will need to issue cards to them as well. Business agility is when bank XYZ can do so, without major activities that need to take place in order to change course. Think about being able to make this business change in 1 two-week sprint.

From experience I can say that an agile business requires an agile IT that has its architecture on track. An SOA, preferably based on Microservices, is the best basis for this. If you ask me, I would stay away from centralized components like single ESB installations for an organization, shared database clusters or API management solutions that are centrally governed. It’s not so much a matter of me disliking these technologies, which I really don’t. It’s about the centralized governance issue, which results in shared resources, which seriously hampers independence. Centralization also means, artificial, restrictions in autonomy. In effect, it means that you reduce your ability for agility.

Now, don’t get me wrong, centralization doesn’t have to be a bad thing. In general it allows you to limit your costs by benefitting economies of scale. It’s a way of improving profitability by reducing costs. There are many situations in which this is the best way to address profitability. Especially in areas where business functionality is established and there is not really a need any more to figure out your product-market-fit, focusing on cost reduction is good. Within the same organization you also want to be able to improve profitability by increasing revenue. This is especially true for those situations or products for example where product-market-fit is a challenge or when the business scope of a product is changing or increasing still.

 

Think back a couple of posts where I explained my stance on Gartner’s Bi-model IT (The BI-Modal Misconception...). The two situations I mention are the closest thing that comes to Bi-model IT that actually makes sense. It’s where the (business) need for change and agility has diminished and functionality is stable vs. where the need for change and agility is absolutely there and business survival depends on it. There’s not a single thing that relates to risk or quality or ability. It’s about the need to be agile or not that defines the need to become agile or not. And typically, Mode 2 is revenue increase focused where Mode 1 is costs focused. Gartner’s emphasis on legacy transforming to the digital world is not relevant at all either.

Back to business agility. This is where the business is agile as established before. And like I stated earlier, this requires an architecture in which the different components are independent and can be independently deployed. Where ‘components’ are ‘products’. Independently deployable components are almost the same as Microservices. And although Microservices is a buzz word, it does have significant merit to base your architecture on Microservices in order to deliver agility to your business. It’s the perfect foundation for business agility.

Which gets me to the point of my presentation on the topic of Continuous Delivery and Architecture I mentioned earlier.

It is a common misconception that Agile and Architecture don’t play well together. Which is over course utter BS, and if you don’t believe me, I posted about this not that long ago (Product Owner and Architect, Agile Tag Team). Agile and Architecture play extremely well together as long as the Product Owner and the Architect(s) play well together. Especially when it comes to Microservices you need the domain architect or the business architect or both when you have that luxury. It is the architect’s responsibility to understand the business domain and together with the PO define what products make up that domain. Every product is a very likely candidate of either become a Microservice in its own right or becomes a composition (or constellation) of Microservices. And the Product Architect, which you might know as being the Application Architect, Project Architect or Solution Architect, is the single one person that together with the PO defines where the Product ends and the Platform on which it runs starts. The Product Architect therefore is the person that defines the (technical) boundaries of the Product and the domain architect defines the product’s place in the IT landscape. And like I said, a product is a Microservice or constellation of Microservices. Ideally, of course. Domain architect and Product architect should also work closely together in defining what API’s to consume and API’s to provide. Again together with the PO since it’s all about the PO’s product.

In this situation, we have a nice decomposition of a product or several products in interfaces and implementations. And that is exactly what we want from an SOA, especially one that is comprised of independently deployable components, services if you will. Or even Microservices.

Once all interactions between products and within products are based on interfaces, we can talk about a true SOA.

Now here’s an interesting detail. Interfaces are nothing but documentation. Be it fairly intelligent documentation or rather very usable documentation, but documentation nonetheless. And everybody that thinks an interface is something else is wrong. We don’t put an interface in an architectural layer because that doesn’t make sense. The same goes for API’s. An API is also nothing more than documentation that conforms to specific standards. Of course it’s a bit more than just a document, but really, just a little bit more. An API without an implementation is nothing and in fact you can’t actually deploy an API, nor can you an interface for that matter.

Having established that, it’s time to start the confusion and get on with it big time.

So, since an interface is nothing but documentation and it’s something you can’t really deploy. In order to provide business agility through an SOA, we need to put something in between interfaces and their implementations… But before I venture into that area, let me explain how you get business agility through an SOA.

We do this by not implementing an SOA but a POA. Where an SOA is a Service Oriented Architecture, a POA is a Policy Oriented Architecture. Basically this is an architecture in which you have services separated into an interface and one or more implementations of the interface. All implementations are available concurrently and based on policies, one of the implementations is selected. The policies are business policies and governed by the business. Business policies are a fancy word for business rules.

An example of such a business rule is that when transferring money between a customer’s own accounts there is no need for additional validation of the transaction once the customer is signed into her internet banking. Another rule is that when transferring money from a customer’s own account to an account of another customer, an additional signature is needed. Both are financial transactions, but based on the context, different business rules apply.

Policies are context driven, which amounts to the notion of under what circumstances a service is consumed as that determines the implementation of the interface to be used. Contexts can be everything imaginable. Within the example of the transaction as mentioned above, it can be the amount of the transaction, the age of the customer, the time of day, the geographical location of either customer in the transaction, the type of accounts, the client device used and the way a customer was authenticated. Or any combination of these contextual parameters or something completely different altogether.

In a POA, there is a clear distinction between interfaces, policies and implementations. The policy sits between the interface and the implementation. And it is business definable, meaning that the business rules can be changed without changing the interface and existing implementations. Either resulting in implementing policy compliance, i.e. some software is developed that implements the functionality to comply with the policy or by implementing another implementation of the service.

Some 10 years ago, Aspect Oriented Programming (AOP) was hot in software development country and although this way of software development is more or less forgotten, it is exactly what POA (see the similarity in acronyms?) wants to establish. By injecting new code, or rather new aspects of an implementation policies can be changed.

The problem with AOP was that was not trivial to do and it was hard to debug once there was an error in the functionality. AOP is also at the class level instead of the service level, and it is far from accessible to non-developers. Still the paradigms of AOP are what POA intends to deliver. A more flexible way of changing nuances in an interface’s implementation.

As you can understand is that the role of the architect and the PO is very significant in POA. The Product Owner needs to understand where policies are to be in place from a business perspective. Not every interface needs policies, and sometimes you don’t even want to have the ability to change a policy without strict governance. The architect, and typically the Product Architect, needs to define how policies are implemented. Since there are as many ways of implementing policies as there are use cases for policies, it is important to at least within the context of a product the same mechanism is used. This is where the architect comes in.

The power of an API, or a Microservice or even a normal service, is so much more when POA aspects are applied as the Product is enabling or rather facilitating business agility. Especially when the used framework for policy definition and implementation is one that allows for doing so by a non-developer. Unfortunately there are not that many frameworks available, most solutions are based on Case Management solutions or consist of glorified Business Process or Business Rules engines. Centralized solutions that require specific expertise to operate and maintain them. Consequently, the autonomity and therefore the agility of the teams and business users are limited. This is where this post more or less started off from. Centralized solutions are limiting agility, and when you want to extend agility to the business, you should limit it in the technology.

So this is how you get Microservices on steroids; apply them in a Policy Oriented Architecture. I hope you liked this post and feel free to comment and discuss. Although the POA is not new, you don’t see it applied that often if at all. I don’t think it’s a matter of complexity or a technology issue. The challenge is typically in that business and IT need to be considered as one and not two separate departments.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect