The Power of Accountability

Some months ago, I had a discussion with a friend and colleague of mine and ever since I’m planning to write this post. This post is about responsibility and accountability.

Summarising

Unless people feel accountability and responsibility instead of just writing it down, RACI tables are a playbook for the finger-pointing game and not a tool for continuous improvement. Accountability and responsibility are the keys to successful products. For architectures this means that they need to be owned, maintained and challenged. Constantly. Continuously.

The reason for the discussion I mentioned was that he was asked to write a short report on the state of the IT department of one of his clients. The issue at hand was that there were a number of serious problems with the IT systems and although outages were fixed fairly quickly, the root-causes were hardly ever addressed. Instead people would blame each other. Fervently. After a couple of interviews, my friend concluded that there was a serious lack in governance in all areas of the organisation. And over dinner we were musing over this whole governance thing. And while enjoying a good meal and afterwards a really nice cognac, we more or less stumbled upon two words that I have been using more and more ever since: Responsibility and Accountability.

So that is what this post is about. This time I’m writing about responsibility and accountability and their role in architecture.

RACI explained

I think that you’re familiar with the concept of RACI tables. Tables in which on a variety of interrelated topics it is noted who is R(esponsible), A(ccountable), C(onsulted) and I(nformed). In my experience, the RACI table is typically very much discussed and eventually agreed upon. But hardly ever relevant in practice. Reason for this is that the RACI table is listed in some document and only looked at when there is trouble.

Let’s dissect the RACI for a moment. I’ll do this back-to-front as that is serving my purpose best. Starting with Informed. This depicts all people and parties that are to be informed about something. Could be an design decision, a contract, a change in a process, anything for that matter. For simplicity I’ll stick with ‘decision’. Then there’s Consulted. Where the Informed are merely told about a decision that has been made, the Consulted are asked their opinion about that decision. Their input is weighing into the decision. The main difference between the Informed and the Consulted is the fact that the Consulted have influence. Informed listen, Consulted talk.

Thirdly, there’s Responsible. I know, it should be Accountable, but I’ll address them last. The Responsible are about making the decision based on their own knowledge and understanding, taking into account what the Consulted said about the decision as well. The Responsible are the people that are all about that the decision is a sound decision. They (should) care about quality. In addition, the Responsible are in many cases also responsible for consulting the Consulted and informing the Informed. I agree with this. Then lastly there is the Accountable. Note the plural in Responsible, Consulted and Informed and the fact that the Accountable is not plural. Accountability is not a team-sport! The Accountable is held accountable for the results, the effects, the impact of the decision.

When we look at this in a Product context, then the RACI is as follows: Responsible is about the production of the Product, the quality of the product and the quantity of the product. The Accountable is about the money made (or lost) with the (sales of) product. Now when you factor in the Product Owner, it should be clear that the Product Owner is all about creating value with the Product she owns. Because of the accountability aspect, the Product Owner needs to find the perfect balance between quality, quantity and cost in order to generate the most value... but the Product Team is responsible for achieving this quality, produce the quantity and keep the cost level stable.
It goes without saying that the relationship between Product Owner and Product Team is to be very tight and based completely on trust.

RACI for the Architecture

You're probably asking yourself where architecture comes into play. I hope you've already read my post on the Agile Architect. In that post I am explaining the role of the architect in an agile environment. Just read it if you haven't already done so.

With architecture it becomes tricky, because architecture can be implicit as well as explicit. Implicit architecture is architecture that emerges. It is the Product Team that is formulating the product's architecture while creating and changing the product. As the product is developed, the team will find, define and adopt practices. Some will become best practices within the organisation as teams share their experiences. But as the team is identifying practices that they find supportive to their product development, they will become an integral part of the way the team works operates and there you go; Implicit Architecture. Mind that architecture is not some soft of diagram with blocks and arrows, instead it is a set of rules by which the product is developed. There's a team understanding that once you live by these rules, the world will be a nice place to live. The architecture is a framework of norms and values. Everybody in the team is held responsible for working within this framework. At best, the Scrum Master can be held accountable for the fact that everybody is following the rules of the team. But with respect to the architecture, this is a stretch.
Once these principles are formalised they become explicit. You'll be able to read them somewhere. The Ten Commandments of the team according to which they develop their products. At this point the team is still responsible for complying with the architecture principles, but since they're written down they need to be maintained. Mind that an architecture is something that needs to be nurtured. It needs to be constantly challenged, validated and maintained. And that should be somebody's responsibility. And that somebody should be held accountable for the relevance of the architecture.

Who da man?

Think about it, once you define an architecture, once you write it down, you create the architecture for somebody to be used. You have created a product. And there should be somebody owning that product and somebody developing that product. Somebody being accountable for the value architecture and somebody responsible for the quality of the architecture. Give it some thought and write down who is within your organisation accountable and who is responsible for any of the explicit architectures. And here's another challenge; ask them whether they feel the same way. For argument's sake, let's call the person accountable 'Chief Architect' and the person or persons responsible 'Product Architect'. And now ask them who they think should be consulted and who should be informed, just to make the RACI complete.

Yeah, that last one is tricky as can be. Traditionally and be aware that tradition is still prevalent, users are informed about products. And traditionally business is consulted about the product. Which of course is all backwards. Which product has the best product/market fit? Exactly, it's the product that meets the needs of the users best. And who better to define what product is meeting those needs best than the user. So users need to be consulted, not informed. I repeat, users should be consulted and not informed. That also holds true for the architecture.
Since the Chief Architect is accountable for the architecture, she will have to make sure that the architecture is relevant. That it is continuously validated for its applicability. Thus, the Chief Architect will need to consult with the developers whether their needs for an architecture, for the architecture are met, and that they can apply the architecture while developing the products. Consequently, the Product Architects are responsible for continuously consult the developers about what they need, how they need it, what works and what doesn't, etc.
In simple terms, the Chief Architect is accountable for the product/market fit of the architecture, and the Product Architect is responsible for making sure that the architecture addresses the needs of the developers. Obviously, when there are domain architects or other more over-arching architects, they befall the same faith.

RACI to solve problems

Now back to the discussion with my friend. The whole accountability and responsibility thing. I hope that you understand that unless the RACI is not only written down, but actually implemented, it doesn't mean a thing and can only be used to 'properly point fingers' when things go wrong. But it will not help you prevent problems. This is because unless you feel ownership, you feel accountable, you are not motivated to pro-actively work on improving your product.
So unless people feel accountable and responsible, they will not consult the right people, inform others in a timely matter and will work on preventing incidents. Finger-pointing is the result. And this is also the case for less obvious products like architectures, contracts, privacy policies and for example employee contracts.

Accept the Challenge

Again I challenge you to name the person(s) accountable for the explicit architectures in your organisation as well as those responsible for those architectures. And I dare you to hold them accountable and responsible. And I double dare you to make them consult their users and not just inform their users. Well, actually, start by asking who their users are, and you are likely to be in for a surprise.

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 contact-list. 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

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

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

Summary

Agility is important, and business agility even more important. With this, the architect has to play a crucial role by defining the right principles, commandments if you will, and seeing to it that the product development teams live by them. Principles like KISS and Independent Deployability are two principles not to mess with. MIcroservices are an important and extremely helpful aspect of this, so is continuous delivery. But you need to get those microservices on steroids in order to be able to move from just agile to business agile. In this first of a two piece post, I am laying the ground works for explaining how you can facilitate business agility in your architecture.

Since you’re reading this post, it’s likely you’re an IT architect or have to deal with one every once in a while. Meaning that you’ve been confronted one way or the other with Service Oriented Architectures (SOA). Maybe you’re even a proponent of this architectural style.
I’m not going to explain what an SOA is, there’s quite a few very good sources available online explaining what it is and why it’s a good way of building your IT landscape, or not. As always, there are just as many proponents as there are people against and SOA. Over the years I’ve grown to like the premise of an IT landscape where fairly small pieces of functionality can be strung together to realize business functions. And with the advent of RESTful web-services, the premise of a true SOA has become more prevalent as ever.

Nowadays all you see and hear around you are Microservices, even though there doesn't seem to be a clear definition that everybody feels comfortable with, everybody is doing Microservices. One of the most interesting definitions I heard is that it is a really small service. But not as small as a nano service. But just to make sure that you know what I refer to when discussing Microservices, here're two definitions I like to use. The first is from Wikipedia, which in and by itself is no guarantee for it to be correct, but at least it's a common definition:

"Microservices is a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services should be fine-grained and the protocols should be lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity and makes the application easier to understand, develop and test. It also parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently. It also allows the architecture of an individual service to emerge through continuous refactoring. Microservices-based architectures enable continuous delivery and deployment."

The second definition is form Martin Fowler, which is in essence the same:

"In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies."

Microservices are not easy to develop, much like API's, they require a rather typical level of maturity of a development team to develop them. The hard part of Microservices is typically the "independently deployable" aspect of the services and then in particular maintaining that independence of time. Let's call it sustainable independence.

What I usually see is that over time the architecture becomes convoluted, resources entangled (the whole HATEOAS thingy is not trivial at all) and adversity against rearchitecting the IT landscape to get back to independent microservices.

To develop them,  the Microservices, you need to invest. In general, a Microservice is way more expensive to develop than a regular service. Much like an API being a lot more expensive than a simple service interface. So I would argue that there needs to be a business case to capture some functionality or resource in a Microservice.

Still, Microservices are a good thing to look into, if not only to be able to dismiss them. But more importantly, they are very helpful in becoming agile. I would almost argue that in order to be agile, you need an SOA based on Microservices and API's. Having said this, I need to emphasise that we're still talking about agility of the product development team, the IT people.

Mind that having an architecture with highly independent units of deployment is a blessing for all of us that want to do Continuous Delivery or Deployment for that matter. It makes life so much easier and as an architect you should really make sure that independence of components, services or units of deployments, however you want to call it, is a prime-directive to all your developers, great and small. It should be up there on the wall with the rest of your architecture principles. First of course you mention KISS and second the declaration of independence for your components.

But as I said, agility so far is technical agility. You've designed your software, your product, for change. Which allows you to be agile. Your PO (Product Owner) wants something different, you can change your code easy as can be. But when you think about it, it won't make your business more agile, it will make your IT more agile.

There's quite a bit more to be done before your business gets its agility... more on that in the next part.

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

Special thanks to Sytse for pointing out one or two textual errors and helping me correcting them.