June 29, 2017

Perish or Survive, or being Efficient vs being Effective


In IT we are not dealing with commodities, although it may seem to be that way, it isn't. Software development is a matter of engineering and not producing. Hence efficiency is not the focus you want to have as a business, instead you want to be more effective. Effectiveness is what is required to be adaptable to a market where changing one solution for another is becoming increasingly trivial. Open standards and the democratisation of IT resources because of the cloud ensure users that the risk of vendor lock-in is negligible. This requires an organisation to be able to adapt to the wishes and needs of its users, not being able to churn out loads and loads of software. Therefore in order not to perish in today's world, effectiveness is needed not efficiency. To thrive in such a world you'll need to be efficient at being effective.

Over the past couple of weeks I had some discussions with a colleague of mine. He's an architect as well and we're in similar situations where we are asked to coach teams and organisations to transition from a traditional setup into an agile setup.

Last week or I was asked by this colleague if I could co-review a report one of his clients wrote that was all about a transition from a legacy waterfall organised project into an agile project. What struck me, and fortunately my colleague concurred, is that the main motivation for this transition was to become a more efficient organisation. Which in fact is an ill-chosen motive.

Let's back-up a bit and consider two similar words that are fundamentally different in meaning: Efficient vs Effective. Traditionally, in process engineering we're striving to become more efficient. The whole idea is that by becoming more efficient, you can produce more and hence benefit from economies of scale and the likes. It's a process improvement adagio that's been around since long. It is also a motive for improvement that leads to silo's, specialised silo's. And here you already see the first sign of why efficiency is wrong when it comes to agile methods. In an agile world we want to get rid of silo's not create them.
So where's the effectiveness coming into play? Well, that's actually rather evident. In order to be agile, you need to be able to turn on a dime at a moment's notice. Which means that whatever you do, you need to be very effective when you do it.

The point here is, that Efficiency focuses on minimising cost by spending as little as possible on the creation of a product on a per product basis. By doing so, the cost of the product reduces and the profit margin per product increases. Typically this is achieved by leveraging specific capacity for specialised tasks. Effectiveness on the other hand focuses on maximising revenue, by spending as much time on value creation by doing what is needed. By doing so, the costs of the product increases but the relevance of the product for the consumer and therefore its value increases more and this has a positive effect on profit. Typically communication lines between dependent parties in a process are shortened by introducing multi-disciplinary teams.

It makes sense to focus on efficiency when you need to produce large quantities of some product, and you know that there's no to hardly any need for diversification. For example when you produce nuts and matching bolts, it makes sense to produce them at the lowest cost possible. Efficiency is for growing your market share with a commodity product. Instead, when you need to grow your business by growing your market instead of your market share. Or where your product is anything but a commodity, efficiency is killing. You'll perish, eventually.

Considering you're in IT, that's most likely why you're reading my blog, your product is anything but a commodity, even when it's a commodity. And growth, especially sustainable growth, is accomplished by growing your market, not your market share. So drop the urge to be more efficient and become more effective.

Point is that you need to be able to adapt to your market. Your user, not even your customer, will initially not have a clue what she needs. Hey, that's why you've adopted agile principles. But once she is up to speed on what her demands are, she'll be more and more demanding. Hence you need to be able to adapt, continuously. And no, it's not adaptation in the IT department either, but your business needs to be able to adapt. And there's the catch, or rather your answer. Because by becoming more efficient in your production line, i.e. your IT department, your business will become less agile. This is because you've optimised the production process and software development is an engineering process. And before you ask, software development is a case of engineering and not producing. That, by the way, is the reason why off-shoring and out-sourcing is so cumbersome.

So you want to be able to adapt your product, you being the Product Owner, as the one being accountable for the company's profit (or loss). Or at least partially. So you want to be able to adapt your product, so it complies with the wishes and definitely the needs of your users. This requires a team that's effective, not a team that's efficient. Meaning that you want a team that can do pretty much everything needed to adapt the product autonomously. Not a several teams that can do specific jobs very efficiently.

This is why you need to focus on effectiveness instead of efficiency when you want to make the move to agile. And I'm convinced that you need to make the move to agile ways in order to survive and not to perish in this world that is changing faster every day. Organisations that are lean, nimble and agile are the ones that will survive in the long run, where the length of long is becoming shorter every day.

So where does this leave the architect in all of this? At the centre of agility. The architect is the one that is perfectly positioned to define what kind of competencies, qualities and personalities are needed to make a team into an effective team. The architect is also the person that is in a position to ensure that a product is adaptable. A product's adaptability and therefore a business' agility is determined by its architecture and the product team's perfectly equipped to make it so. More importantly though, the architect is in a rather unique position to not only ensure that product teams are effective and business becomes agile, but also be very efficient at this. Only when you architecture is in order and your team is effective will you be ready to improve on your efficiency, allowing you to not only survive but actually thrive.

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.


June 12, 2017

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


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.


June 8, 2017

‘The Continuous Delivery IT Team’ fallacy


Considering Continuous Delivery something for your IT department is throwing your money out the window when doing an Agile Transformation program. If you want to do so, make sure you throw it into my direction. IT is a business concern, Continuous Delivery is a business concern.

Over the past couple of months I did a series of awareness sessions on Agile, Continuous Delivery and DevOps at a large client of mine. As is rather common, also at this organization the initiative to move towards Agile ways of working, Continuous Delivery and a longing for DevOps is with the software developers. This makes perfect sense when you think of it, because it's the developers that want or rather need to make changes and the pace by which they have to deliver changes is only increasing. But I guess I don't need to tell you this.
But Continuous Delivery (or Deployment for that matter) is only possible when you don't consider it a software development thing. There really is no point in spending any time to move to Continuous Delivery when you are not planning to do it broadly. I'll get to that in a second.
During these awareness sessions, which I do with colleagues from the same team, we discuss with non-developers like risk officers, sys admins, project managers, architects, test consultants, etc. we outline what Continuous Delivery and DevOps mean within the context of my client's organization. It's a common story and I won't bore you with the details, but obviously we touch upon the benefits of small increments, feedback loops and so on. And the fact of the matter is that our story actually does sound like it's the perfect thing. And we consistently get the question: "So, really, it can't be all awesomeness, so what's the catch?". And in the rare occasions we don't get this question, we still answer it.

The biggest problem with Continuous Delivery and everything following from it, is that it is not a software development thing, or even an IT thing. When you think so and still go down that road, spare yourself the frustration and disappointment, drop me an email asking for my IBAN number and transfer the budget for your transformation project into my account. At least one person will be happy with you spending that money.
And yes, even when you think it's an IT thing, you're better of giving me that money. This is what I call:

'The Continuous Delivery IT Team' fallacy

Let me explain. First of all, let's make sure you understand what I consider Continuous Delivery. It's the process that produces a product that results in business value in order to be able to sustain the organization up to the point that it can be delivered to a user and it will be delivered to a user as soon as possible. It's not a perfect definition or even a formal definition, much because there's so much more to it. But what's important is that it defines work on a product as being done, when it is ready to be delivered to a user. The actual delivery is an explicit manual step which is decided by the Product Owner to be taken as where the rest of the process is preferably fully automated. This as opposed to Continuous Deployment, where the delivery to the user is also automated and hence triggered by the developer when committing his code to the source code repository. Again, this is a definition close enough to what it is and fitting the purpose of this post.

With Continuous Delivery and agile working in general you want to receive feedback for what you've been doing as soon as possible. And preferably you want this feedback to be such that for one you know that you've done well and secondly you're actually contributed to the bottom line of the organization you work for. This is why we like to work at the granularity of user stories and epics and delivery on a per user story or at least on a per epic the changes to a user.
As you now understand, for every single user story or at least epic, you need to do everything that needs to be done for a release, because you're delivering to a user. Somebody is going to actually use that little piece of software you've worked on with such a passion. Fact may be that the complexity is limited because increments are small, still you need to release new or changed software. And there's the catch.
With software delivery, or product delivery in general, it's not just the product development team that's involved, or more specifically the software development team. It's other teams and people involved as well. Think about marketing, legal and compliance, worker's associations, security and risk management. These are all teams that are not part of the IT department. And no, security officers are not part of an IT department, and in case they are, they most definitely shouldn't be. And the biggest catch of all, the 'business' needs to be involved from day -1. Unless all of these different roles, teams, people, stakeholders, however you want to call them are on board and work in those same small increments, not becoming a bottleneck and automate as much as possible, your Continuous Delivery efforts are a waste of everybody's time and your organization's money.
Back to your 'business', it's them that request for features and not the user. It's them that pay for the development of the product not using it per se. When that 'business' is not capable or willing to define the product's features such that they can be delivered in tiny chunks, than you're out of luck and not much will come from Continuous Delivery in your organization.

The Product Owner is key in all of this. Being the hinge between the Product Team and the rest of the world, the PO is the single one person that can and must ensure that the product is delivered incrementally, with business value visibly added with each increment. PO can't do this, you've got yourself some trouble. The PO, at all times, must be able to relate every single feature, one way or another, to an improved life for the user of your product and therefore a positive effect on the organization's bottom line.

So, Continuous Delivery is not an IT thing, it's a business thing. And don't let anybody convince you otherwise. Being as it is, moving towards an Agile way of working and Continuous Delivery or Deployment, in fact would mean that you no longer consider your IT as being delivered by a separate IT department, but as an integral part of your business.
This does make perfect sense, considering your IT as part of your business I mean. It makes perfect sense because more and more business are all about information and are run based on information. IT is no longer a tool, like a glorified typewriter, it is in fact what is producing business value. No IT no business.

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.


June 7, 2017

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


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.


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