Why CDM resonates with Waterfallians and not so much with Agilisto's

Architecture often is a matter of perception.

Architects that consider that architecture to be a noun, often consider, for example, that a CDM (Canonical Data Model) is a solution to a problem. Architects that consider architecture to be a verb, are very likely not considering a CDM at all. And although I have very strong personal feelings against architectural artefacts like a CDM, I'll try to explain in this post, why they can be perceived as an addition to an IT landscape. I think that is also very much an issue with a historic touch.

The School of Waterfallians

When you're a Wterfallian, when you come from the Waterfall school, then architecture is part of the analysis and design phase. This phase ends with 'The Architecture'. And that "picture with the 1000 words compendium" will have to last for the rest of the project. So you have to design something, come up with an architecture that will remain unchanged for months if not years. Your data model is obviously part of your architecture and will be included. Soon you'll draw the conclusion that a durable architecture requires for CDM, because how else can you ensure that your design fits within the landscape of existing and future designs?
If you have been raised with the standards and values ​​of a waterfall organisation, then you also know that deviating from previous decisions is out of the question. That only causes delays and budget overruns. Waterfallic architects will often focus on edge-cases, because they have the experience that these are the reasons to double back on previously made decisions. Logical behaviour is therefore also that you want to have it, your list of edge-cases, as complete as possible before you get started. Waterfall is a self-reinforcing approach when it comes to architecture and culture.

The Agilista School of Architecture

If you come from the agile school of architecture, then architecture is part of the development phase. Architecture emerges. The architect is thus a developer, or better said, the developers create the architecture. The agile architect therefore only design the rules-of-engagement, they merely create the play-book. A comply-or-explain concept ensures that the architecture can emerge and the best architecture at that point of time can be defined by the developers. The best architecture within the current context emerges. So you do architecture (verb), and you do that by adhering to the rules. This is a continuous process, you have to play by the rules continuously. When we look at a CDM, we find that the CDM itself is not that exciting in an agile world, instead the rules that a (C) DM has to comply to are. They are the grammar of the language.
When you were raised with the norms and values ​​of an agile organisation, then you also know that sticking to earlier made decisions is out of the question. At least, if this is against better judgment. That only causes a huge waste of resources instead. The agile architects will focus on the most common cases, because they have the experience that these have to be realised first in order to create value, validate hypotheses and provide insight into the next steps to be taken. Logical behaviour is therefore also that you want to have the first use-case defined as soon as possible in order to get feedback. Agile is also a self-reinforcing approach when it comes to architecture and culture.

Culture and Values

The crux is in culture and therefore in standards and values ​​and therefore in accountability. When the performance of an architect is measured based on the number of times that decisions have to be reconsidered, then an ever decreasing number of this metric is, for a waterfallian, an indication that things are improving. For the agile architect the opposite applies and an ever increasing number of reconsiderations will be better... or not.
Because the agile architect does not double back to earlier decisions, as the agile architect tries to find the best decision for a situation every single time again.

Hmmmm, then how would you evaluate the performance of the agile architect? That question is in fact not that hard at all to answer. The agile architect is not about the architecture but about the rules. The more stable they are, the better. At the same time, the rules have to be sufficiently complete to be able to develop products that offer the organisation a bright future.

The Architecturally Challenged

Who has the more challenging task? The Agilista or the Waterfallian?

That can not be answered, because they can not coexist. But it does make it clear that both have a big challenge. Each in their own system.

The waterfallic architect is mainly concerned with analysing and specifying everything in advance. It is someone who is good at overseeing many concrete aspects. She is someone who knows a lot, someone who thinks in as-is and to-be. That is to be expected, because in a waterfall organisation the architect is often the person with the most experience with a product or product group. The focus is mainly on 'what' and 'how' in the 'why, what, how' system.

The agile architect is mainly concerned with understanding the dynamics of the organisation. She is someone who is good at working at the abstract level and thinks in concepts. It is someone who understands a lot, someone who thinks in from as-is towards to-be. That is to be expected, because in an agile organisation is often the architect who has the most experience in how the organisation has developed. The focus is mainly on 'why' and 'what' in the 'why, what, how' system.



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


The text very explicitly communicates my own personal views, experiences and practices. Any similarities with the views, experiences and practices of any of my previous or current clients, customers or employers are strictly coincidental. This post is therefore my own, and I am the sole author of it and am the sole copyright holder of it.

A Treehouse for my youngest son

In 2015 we, my family and I, spend our summer vacation at the Mediterranean. Although this is irrelevant for this post, what is relevant though, is the fact that our youngest son, was watching Treehouse Masters on sat-TV.

This is a TV show where a group of professional Treehouse Builders (if there is such a thing) are building the most awe inspiring treehouse you can think of. And he was awe-inspired. You have to know, our son has had many great ideas about remodelling our home. One of these ideas was to make a hole in the floor of his bedroom and install a slide. This would allow him to be quicker downstairs when called for dinner, and he would have more time to play. We, my wife and I, try not to discourage him by telling him it can't be done. Instead we agree to most of his ideas, but he has to figure out how to realise them. Taking permits, structure integrity, budget, etc into account. We're willing to apply for anything needed in case a grown-up needs to sign a paper, but the tinkering is completely his responsibility. We always come out in a win-win situation. Either he finds out it can't be done, or we find out it can be done.

Anyway, he was going to build a treehouse in the fashion of the treehouses in that show, as soon as we would be back in the Netherlands.

You might be wondering what this has to do with agile architecture. I'll try to explain.

What happens in this TV show is that the team building that treehouse makes an amazing design and start building it. They do this within 60 minutes, the duration of the show. Of course in real life this will be longer, but typically they will have the treehouse done within a couple of days. One of the things they never show are the costs involved with building the treehouse. And with that, they also omit the costs involved with keeping the treehouse inhabitable. I'm using that word, inhabitable, consciously because those treehouses are really of the kind you could live in without 'of the Apes' being your lastname. My guess is that most of the treehouses (ever wondered why it is houses instead of hice? Since the plural of mouse is mice?) cost a couple of thousand €'s to build. And I wouldn't want to think about maintenance costs. Considering that most of the construction material is wood, you'll understand that there's a lot to be done to maintain it. To my son, although he's a really smart kid, it feels like they build the treehouse in minutes and for free. Not to speak about the running costs. He was 8 at the time. We forgave him his naivety at the time.

It's not a lot different from running a product in the Cloud actually (don't know why I always write cloud with a capital C, well almost always). When you take some time and watch for example Amazon's video's on AWS, you see how easy it is to use the many services of AWS. Amazon has done a great job in that. One of the things you are not seeing are the costs involved in building your SaaS products. Nothing about time nor money. Just like the Treehouse Masters never disclose anything about costs, structural integrity, maintenance etc. The tutorials nor the training exercises mention the AWS equivalents either. The tutorials and training exercises do mention different aspects around your architecture concerning reliability, stability, resilience and security. But it is all very generic.

Back home in the Netherlands, our son came up to me telling me that he was going to build a treehouse. He wanted me to film the endeavour, so I took out my GoPro Hero 4 Silver with the Gecko stand I got from a KickStarter project I backed. I asked him where the tree was where he was going to build the treehouse. It was going to be the apple tree in our garden. Only we quickly discovered that its branches would hold the treehouse. So the on-premise solution would fit, just not enough resources available, hardly scalable and other than being really close to home not suitable. Close to home was good, he would be at the dinner table quickly. Remember the slide earlier on in this post? Yup, not a lot of latency there, it was actually a solution you see a lot with on-premise solutions, you can bring resources really close to each other. I will not insult you by explaining the analogy, but feel free to explain it to show off your awesomness in the comments below.

Like pretty much everybody in the Netherlands, we all have bicycles so my son took his and was on his way looking for a suitable tree. After a while he came home, all excited, he found the perfect tree. I took the GoPro and we went to 'his' tree. It was a 25 minute ride. This was an issue and he realised this immediately. A roundtrip of 50 minutes would be very cumbersome for him, especially since his treehouse would become sort of a satellite of our home if it were up to him, it would use up about an hour of processing, uhm, playtime every day he was going to enjoy his very own treehouse. But he figured it would be worth it. He could use the extra exercise. Really, building and sort of living in your own house. Up in the trees? How cool is that? And by all means, it was an excellent tree. Perfect branches, not too high up and accessible without having to cross busy roads. It was everything a great cloud solution would offer to us, great infrastructure to build our solution onto, low entry costs and excellent connectivity. Yeah, that analogy still holds.

While we were at the tree, I took out the GoPro and our son started climbing in the tree. He loved it. And what do you know, there was a little higher up in the branches a sort of ladder. He could reach the higher branches by using it. Apparently he wasn't the only kid in town that knew about the tree and thought it was awesome. Yup, he was going to face some sharing of resources when using this tree. And that got him thinking. The tree was clearly big enough to have more than one kid playing in it. I mean it was an oak tree and virtually reaching all the way into the clouds. Well, in the fog it would be in the clouds. So that was fine. But what about his treehouse? How could he make sure that the other kids wouldn't get into his treehouse without him knowing about it and granting access? Yup, he needed to do some tinkering about that. Definitely. And he needed to figure out how to handle the construction of the treehouse as well. It would take some wood, plenty of nails and a hammer. A hammer we had, but the nails. Or the wood. And the expertise to really make it a save treehouse. Some tinkering was required.

Even though it seems so easy to just go into the cloud, create an Amazon account or Microsoft Azure or Google Cloud, enter your credit card details and you're good to go. It's really low entry. But once you really understand what your objectives are, you understand that you need to think about the fact that you share resources. You're connected to the internet so security really is something to wonder about and you will need some new tools and technologies in the cloud with the right expertise to benefit from what the cloud can offer. In a safe and cost effective way. Just like our son has parents that allow him to experiment, come up with new ideas, tinker with them and that help him with all the 'hard stuff' needed to first consider feasibility, then viability and eventually really build that treehouse, the Agile Architect should be available to you to help you with all the intricacies of the Cloud. Working together with you building the best solutions within the right context.

Concluding

That treehouse? Well we got some wood from the local DIY store and the proper nails. We went to that tree and created a platform. It was his Treehouse MVP. We used it to see how often he would actually go there to play, to see how many kids would (try to) use the platform and whether or not he would like to play with them. The MVP cost him €23, that's without a k and a full day of hammering about. Two weeks later he had a bright(er) idea. Instead of building a treehouse, he was going to build a sales-booth to be placed in front of our house and he was going to sell the apples from our tree in the garden. The treehouse he originally envisioned would've cost him about €1,700 in building materials, not to mention the security system he thought was needed to keep the other kids out of the house. He saved €1,677 by starting small. He made that fall about €30 selling our apples. Which were donated by me to the great cause of teaching my youngest kid to think big, start small, to learn and to adapt.

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


The text very explicitly communicates my own personal views, experiences and practices. Any similarities with the views, experiences and practices of any of my previous or current clients, customers or employers are strictly coincidental. This post is therefore my own, and I am the sole author of it and am the sole copyright holder of it.

What makes an ideal agile team?

Summarising

In many occasions I am being asked by clients to share my thoughts on how they are (planning to) form their Scrum teams. My recurring comments always are to have the team as small as possible, stable and consisting of full-time individuals, maxing out at 9 persons. Have one or more coaches linked to the teams and make sure that there is a mandated Product Owner.
Make sure that relationships are based on trust and ensure that accountability and responsibility are two aspects addressed organisationally with full support of upper management.

The other day I was asked by a manager of one of my clients to comment on a proposal of one of his vendors. A key vendor that has been under delivering since a very long time, but still considered to be a strategic partner in most of my client's business. The vendor is currently experimenting with a different way of addressing its customers by better aligning its services to the needs of its customers. The vendor is proposing to setup a cross-functional team that will be tasked to deliver relevant products in short cycles.

My client is a little sceptical but willing to give the vendor the benefit of the doubt. As such he's agreeing to become one of the first customers to work according to the new proposed process and is now asking me to see what to look for in the proposal. Being the first customer and thus investing time and effort in amending the current mode of operations with this vendor, there's some head room to 'ask' for specific adjustments to the proposal.

The vendor is going to deliver new products and services in a variety of categories to my client and is proposing to setup a Scrum team. My client now wants to know if there are specific aspects of this team that need to be addressed. Also the role of my client with regard to this team is a point of interest in the negotiations. And obviously the delivery of products and services to my client.

Basically the question is: How should my vendor organise its team in order to better meet our requirements? The answer is reasonably straight forward.

In principle you want to keep a Scrum team as small as possible, that is actually a basic principle. The maximum size for a well-functioning team is 9 people. This has already been discovered by the ancient Romans, no kidding.

I would like to argue to start with 6 or 7 people. Rather 6 than 7 by the way. The reason for this is that otherwise you will get specialisations within the team that come to lie with one person, that will immediately become the SPOC / F, who can not get sick or go on holiday.
The strength of a well-collaborating team lies mainly in the knowledge spread throughout the team as well as complementing personalities of the team. This allows members to challenge, supplement and assist each other. It is a common mistake to see what kind of techniques and technologies you want to use and to find the experts for that. It is a Team and not a Group we're trying to forge. Understand the difference, it's important.

I find the use of FTEs in resource planning of Scrum teams confusing and dangerous. I've seen this plenty of time and it never resulted in anything good. One FTE can be filled in by 1 or more people, and that is what you want to prevent. You want the team to be stable, not only within a sprint but also over sprints. Almost at any cost. Again, I'm not talking about a group but about a Team. And, they must all have an engineering mindset. People who dislike doing things themselves and want to automate everything by definition.

Recently I was asked on the subject within the context of an initiative to start treating an operating environment as a platform, which was going to be treated like a product. With a Product Owner at the helm. And a group of my client's experts was assembled to form the 'Scrum team'. I was asked to provide my thoughts on this setup.

We're talking about server provisioning, networking, identity and access management, firewalls, certificates etc. This team is also going to be responsible for operating the platform they're developing. My initial thought is to have therefore functional expertise (provisioning, networking, identity management, loadbalancer, firewalls) and an engineering mindset (automating, monitoring, everything as code), if possible either a senior in one or more functional areas and medior in engineer and vice versa. Depending on the team composition, there may also be a medior / medior combination when there's enough seniority in the overal team. Attitude is more important than knowledge in my opinion. I would therefore always prefer someone who wants to automate, will always test and always asks for insight into production.

I do not see why one would need a full-time Scrum Master, that's probably overkill. Having said that, it seems wise to let the team choose their Scrum Master from the team itself. And with experienced teams that have been working together for a considerable time this is likely a viable option. But when you're just starting with Scrum in your organisation or when the team is just starting with Scrum and Agile concepts, I always prefer a Scrum Master from outside the team. Since the Scrum Master is the team's conscience, and at times will have to use strong words to get focus back on the team's goals and principles... it will be challenging for a Scrum Master from within the team.
Add a coach for roughly the first 6 sprints to coach the Scrum Master, even though the Scrum Master might be experienced, it is still good to have a coach. The team chooses the Scrum Master because it will ensure that it's their choice, a choice supported by the team. You want good chemistry between team and conscience.
The role of the Scrum Master is all about addressing people to the standards and values ​​of the team, but also facilitating them in doing their work. I have seen in various situations that it can work when the Scrum Master is also facilitating in another supportive role, e.g. as Tool integrator in Continuous Deployment environments. I'm not a proponent of this though.

I told the client that I was missing the Product Owner (PO) in his approach. The PO is relevant because the PO determines what the team is going to work on. That would be the person who talks to the customers about what is needed, etc. And to the users about what was delivered. Therefore the PO is accountable for what the team will deliver. The team is responsible for what it creates, the PO is accountable. These are the two most important aspects.

Keep in mind that responsibility can be delegated and shared, accountability cannot be delegated nor shared. So a delegated PO doesn't exist, as it would mean delegated accountability.

So a stable team and a PO (outside the team) defining the team's priorities. No one else but the PO is mandated (i.e. empowered) to determine what the team is working on, because the PO defines the priorities of the products and features to be developed. The team plans the work. So there has to be, by definition, a lot of trust between the PO and the Team, because the PO must be able to rely on the team's commitment to what they are going to do in a sprint. Here comes the Scrum Master in the picture again. Because the Scrum Master has to make sure that the team does not overcommit.

Here's an interesting aspect, the trust aspect. An aspect I will address in a future post, where I will cover more on metrics and KPI's and the trouble of the user story in this regard.

In my opinion, the role of customers should be not only one of the customer, but also one of the user. This will allow a user-centric approach on developing the product, and at the same time be very customer aware.

You should look for a future post on stakeholder management and agile processes to get some more insights on this topic.

I told in another case with another client of mine that it makes perfect sense to start treating their Scrum teams as internal startups. Basically consider the PO of these teams as the CEO of the startup and the management team would be the Venture Capitalists. By doing so, there's ample opportunity to experiment and evolve into a value driven minded organisation.
In this particular case I suggested to see if it would be feasible to go along these same lines.

The PO will need to determine what an MVP would be. Something small delivered in short increments, so to quickly find out if something is usable. Start cultivating a mindset where 'Done' means 'In use at a customer!' (Done = Live).
Agile means being able to deal with change in a timely manner. So here comes the point of view that the PO is a person who has a strong personality and is met with a lot of respect. Somebody that knows what the product should look like, with a product vision. And the PO will have to be mandated/empowered. It should never be the case that the customer can circumvent the PO to get things prioritised. This is for internal and external customers. And managers.

Again, I told my client to get a coach involved here as well. Even if it is an experienced PO, it is important to be coached. In the beginning intensive, but perhaps later (even after 6 sprints) it may be a bit less. It might be an opportunity to invest in an agile-coach, who will take care of all the coaching work (team, Scrum Master and PO).
Just like the PO is mandated to define what is and what is nog going to be in the product, the Team and the PO should be granted autonomy, independence and self-reliance. The PO is positioned external to the Team and in case of scaling up the team to two teams I would like to argue that both teams get the same PO.

In this particular setting, one could even consider starting with three small teams of 3 to 4 people who all work on their own part within the platform, three products if you will. A team for provisioning servers, one that works on network and connectivity (including DNS, firewalls, loadbalancers) and a team that focuses on IAM Automation (Directory services for example) and certificates. Combine these teams with a single Scrum Master and a PO with three Teams. Obviously an Agile coach for the whole bunch.

So, concluding: A maximum of 9 individuals, all full-time, in the Team. One of which will assume  the role of Scrum Master. Alternatively, form 3 teams of 3 to 4 full-time individuals with an overarching Scrum Master. In addition, a PO with knowledge of the subject matter and full mandate and an agile-coach.

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

The "Eat your own dog-food" fallacy

Why having people eat their own dog-food doesn't accomplish anything sustainable.

Summarising

Having somebody eat their own dog-food doesn't necessarily make the improve its taste but might make them get used to the taste instead. Awareness of the (lack off) quality in one's work is important when transitioning from a Dev/Ops organisation towards a DevOps organisation. But experiencing a lack of quality first hand is often not the way to do so, or even an option. Agile transformations are only possible by means of cooperation.

There's a common understanding in the world of organisations that are transforming from Dev/Ops towards DevOps organisation that this works best when the devs are forced to eat their own dog-food. It's a reaction from the Ops people towards the Dev people.

Basically it means that once you've got the Devs supporting their own products, they'll make sure that those products are of a high quality. Common believe is that since they, those Devs, don't want to get called Sunday night at 3 AM because their software crashed. Which makes perfect sense, who does want to get called Sunday night at 3 AM because something they created crashed? I wouldn't, would you?

So, if you want those Devs to focus more on quality, on less crashing software, you have to make them support that same software themselves. In other words, turn those Devs into Ops people and that'll show them.

About a year ago, I joined a team at one of my customers to help them transform selected development teams into more agile teams utilising Continuous Delivery mechanics and move towards, lord forbid, DevOps. One of the slogans we used to get the necessary buy-in was:

"Eat Your Own Dog-Food"

And later we added "And Clean Your Own Shit!". Totally convinced that this is how it works. Make people feel the pain they're causing and they'll become better persons. If you would do a little time-travel and rewind about 2 years, you'll hear me saying that "one should feel the pain they're inflicting".

I think you'll recognise this when you've been in that situation where you want to move from Dev/Ops towards DevOps. Or become more agile. Or maybe you need to convince people that agile or DevOps is the way to go.

It makes total sense. People with kids know this. You want them to stay away from the fire, let them burn their fingers. Or those people with dogs shitting all over the place... let them clean that shit every time their dogs drop their poop in the playground. It works, really does.

But there's a huge problem in this, I'll get to that. First I want to ask you if you've noticed that slightly grumpy undertone in me mentioning of the "Eat your own dog-food" slogan and everything associated with it.

Agile and SCRUM in particular are developer driven ways of working. It's the developers that want to change things. Reason, obviously, is that developers want to develop software that people are using, so they want to get create something that is as close to what is usable as possible. Meaning that they want so put something in the hands of the user as quickly as possible and then make adjustments and put that into those same hands. And again. And again. And again.
Our organisations are such that specialised Ops people are managing those applications when in the hands of those users. And they need to keep up with all those adjustments... You understand the predicament those Ops people are in.
So when you tell these Ops people, that you want on your side while transforming into agile organisations that those Devs should eat their own dog-food. Ever tasted dog-food? So how do you think that this resonates with those Ops people? Pretty awesome, don't you think?
That connotation of dog-food is getting the nay-sayers called Ops on your hand, shouting "Yay" instead of "Nay". Mission accomplished. You're done.

Well forget it. That's the "Eat your own dog-food" fallacy. It's a fallacy because it doesn't solve anything and it certainly won't help you in your agile transformations. Considering your organisation has separate Dev and Ops teams, and considering that the reason for this is a more efficient Ops team because they will support many products. Because supporting a quality product is not a full-time job. Read my post on this topic. There's no way that having the Devs eat their own dog food will improve quality. Which was the premise in the first place, remember? And now you should say that in fact it doesn't make sense at all. Because there's an Ops team and for a good reason. So what makes you think that anybody in the organisation will just allow the Devs take over the Ops jobs? Ain't gonna happen. No way. Meaning that whatever you're trying, the Devs won't even get the opportunity to eat their own dog-food, even if they would want to. You can fix it by job-rotation... in certain situations, in certain organisations. Fallacy explained.

Considering the above, how would you need to address the agile transformation? How to move towards a DevOps setting? The answer is quite simple and probably extremely hard to implement. The more alluring the "eat your own dog-food" approach is, the harder it will be to do the correct thing. The sustainable approach, let's call it.

If you want the developers to develop software of a higher quality, you need to make them aware of the problems they are causing because of the lack of quality in the software. And you do this, by introducing them to their operations colleagues. Let them work closely together. Geographically close. As in side by side. Not pair programming close, but across the desk close.
What will happen is that the colleague from Ops will complain to his Dev colleague about a problem instead of to his Ops colleague. Feedback loop is tiny and closed. And most likely, it's friendly constructive feedback, because it's directed to the immediate colleague from across the desk. That person with whom lunch is shared. Not bottled up feedback. It becomes a feedback loop in which the Dev can immediately ask the Ops person why it's such a huge problem, this tiny thingy.
Getting the Dev and the Ops to work at the same desk, allows them to become aware of each other's work. And generates understanding. Understanding towards their respective worlds. It creates an atmosphere where the Dev will improve the quality of the product, because otherwise the Ops colleague is called Sunday morning 3 AM, and that's not something the Dev wants.

As a parting gift, another tip: Make sure that Devs and Ops don't huddle together when you put them in the same room. Instead put the Dev next to the Ops, side by side, hand in hand. When you allow them to huddle together, you should put them in separate rooms. Just to make sure that their respective complaining is not effecting them during work hours.

By allowing those to blood-types in your organisation to become aware of each other and befriend each other, you'll pave the way to become a true agile organisation with a smooth transition towards a DevOps mindset.

Here's an exercise for you: See how it works the other way around. Feel free to use the comments to discuss.

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.

Product Owner and Architect, agile tag-team

Picture yourself in an environment where agile practices are adopted as the standard way of developing solutions. Now if you're really ambitious, you're picturing yourself in an environment where there are no projects, only products. Consider yourself to be part of a team working on a product, a product team. The team is comprised of all the necessary expertises to create the product it's developing. The team you're part of is responsible for the product, cradle to grave.
But wait a minute, are you really part of the team? Or are you external to the team, but do consider yourself heavily involved with the team? You might be the Product Owner or an architect.

Is the PO not part of the team? Maybe, maybe not. It's not that important actually. And what about the architect? Is the architect not part of the team? Well, the architect, I would think and this is just my very humble opinion, is not part of the team. The architect is concerned with the team, but not this team, but all the teams that are in the architect's domain. The architect is there to ensure that the products form a cohesive landscape that, by synergy, creates the most value for the organisation as is thinkable. Back to the PO. The PO might own many products in a portfolio...

Your picture. Did you picture yourself in this organisation as part of the team, of a team, or as somebody outside the team? It doesn't really matter too much. Really.

The interesting part of such an organisation, be it a for-profit or a not-for-profit or even something governmental, such an organisation is catering for its business, for the users of its products. And the products are there to generate value, pure and simple, life's better with every new version of the products the organisation releases. The product teams are there to work on these products, to make sure that the users are actually able to use these products and once they have those products at their disposal, they can continue to use them.

Other than in more traditional organisations where products are developed in projects, where there is a project organisation and a operations department to keep the solutions running. In these organisations teams, the project teams, are only concerned with getting the products out. And in many organisations it doesn't even goes as far as that and the project teams are primarily concerned with ensuring the products are accepted by the operations department. This is how these organisations work, and this is how teams operate. That's not to say that the individual members of the teams are not concerned about the quality of what they create or whether or not users actually like their products and use them. And that's not to say that the people working operations department are not concerned with the development of the software and that the quality is great etc. Organisationally, there's a divide and more importantly there's no one single entity that is responsible cradle to grave for the products.

What about this tag-team, this agile tag-team?

The effectiveness of the PO-Architect team, this tag-team, is the greatest in this product oriented organisation. The more 'agile' is considered a business trait instead of just an IT trait or even solely a software development trait, the bigger the impact the tag-team can and will have on the bottomline of the organisation, in a positive way.

Here's why. The PO, when peeled like an onion is at the core only caring about creating business value. And the PO has two currencies that he can use to invest in order to create even more value. For one there's the crude oil of product development: €'s. Here we have the simple fact that the the business needs to be able to earn more money with the PO's products than the PO had to invest in creating the products. It's a simple matter of cost/benefit and ROI. The less the PO needs to spend, the more the business makes and the shorter the time for the business to earn back the investment the better.
But there's also the second currency, which is time. Time taking to create the product, or a new value creating feature of an existing product. Time has no ROI. You have to invest time, knowing you'll never get it back. You might save time with your product, but the time you invest, you can only invest once. This is important because you want to invest as little of that time in something that generates the most value. Think about this for a second... what it means is that you want to create a new product (or feature) that will generate the maximum value in a minimum timeframe. The crude oil, your €'s are secondary to this, as a PO, because you have a product team available that you need to pay for anyway. Remember, you're working in a product oriented organisation not a project oriented organisation. Your teams are pre-funded! This is also important to note.

So the priority of the PO should be generating as much business value as possible. Therefore the PO needs to prioritise the various products and their features such that the most value creating features are worked on by the product team first. And this is extremely tough for the PO, especially when the PO is not a business person because the PO needs to know what's good for the gander as that is good for the goose.
And in many cases the PO will need to experiment in order to find out whether or not a feature is really needed. Whether it is really going to be used. Whether the form it will be delivered in is the most optimal form. Experiments cost time as well, so the balance between experimenting and applying is critical.

This is where the architect comes in. Without the architect the PO is lost, or at least the PO is susceptible to overspending. First of all, the architect's view is more than just a product and is therefore prone know about solutions to partial problems available elsewhere in the organisation. And leverage them. The architect is the right person to lay the foundation for future features. In part by ensuring that there is a generic (application) infrastructure that can be leveraged throughout the lifecycle of the product. When the PO has the insight to define a product roadmap or a business direction for the product(s) to evolve in, and shares this with the architect. The architect will be even better equipped to pro-actively define the foundations of the products, where a little investment upfront pays itself back at a later stage. See the parallels with the PO, the architect is there to understand where and how best to invest product development time to save more product development time at a later stage.
But there's more, obviously. The architect, and this is the 'secondly' belonging to the 'first of all' from above, is best equipped to define where what corners can be cut for most impact and what experiments to run in order to get the most out of new or specific capabilities. The architect will be the single one person that understands how to scale the organisation's technologies. How to move from a simple, crude yet effective archaic technology to a more complex, elegant and sophisticated version and when to do so. The architect therefore can and will save the most valuable currency of the PO, feature development time, at every step of the way.

Remember that PO and business value creation? Value should be created as quickly as possible, so short development times are important. As much as possible value should be created, so the most desired product features with the biggest impact on the bottomline should be worked on by the team. But which are these features? Well the architect doesn't know these answers, but is perfectly suited to limit the amount of time it takes to either develop a feature or to find out what feature should be developed by devising an experiment. The PO still needs to run the experiment though.

Ah, here comes the hardest part of the post. How to set the right priorities? Which is a question the PO will need to answer. The common way to do this, the wrong way indeed, is to work on the simplest feature to develop. Or the one that can be delivered the fastest. Often these are the same features by the way. This will only result in the PO and the team to feel really good about themselves because they added many features to the product. Something that will in most cases be far from adding the most business value to the product.

Again the architect is a great team member for the PO in this as architecture is not about simple to develop features or quickly realisable solutions. Architecture is about ensuring durability, sustainability. It's about creating a playing field in which complex solutions can be developed quickly, because the groundwork has been done already and therefore a solid foundation is present.

The challenge is with the PO still as business value should be the key to the priority of the feature backlog. So with every feature the PO will need to define how much value will be created, preferably in terms of what will be changed, and what will be the benefit of the change. From a user's perspective, always from a user's perspective. The PO will also need to establish a baseline for each feature he's planning to invest development time in. This is for the simple reason that there's no way to determine whether or not you've improved life as you know it, without knowing what life is before you started your improvements. And consequently, the PO will need to start gathering the right metrics in order to know those improvements. Defining the reason why you want to change something, i.e. defining what the benefits will be, will more or less define what metrics will show progress and therefore what needs to be done to establish a baseline.
Leaves the PO with defining the top priority of all the features that need working on. And this is encoded in the metric used to measured progress and the reason for the change to be developed. From these a projected generated business value can be established.
And this is where the architect can shine again. Not with this little piece of math, but with the part about metrics and measurements. The architect will be the instigator of the existence of a set of architecture principles that allow for metrics and measurements. Principles that lead to the existence of comprehensive measurements, to profound standardisation of those aspects that need no specialisations, to extreme automation of setting up environments. This can be left with the product team, but when there are more than one team, there will be a need and at the least a benefit, of coherence across teams, which is where the architect is acting.

Concluding, the PO and the Architect make a wonderful team that jointly work on the best prioritisation of the feature backlog for the products of the PO. By doing so, they'll minimise the required investments in feature development time for the product team to develop a feature, all the while maximising the created business value. And as icing on the cake, they are in the process ensuring that the hypothesised improvements are validated. You want a cherry on top? With this awesome tag-team you have a perfect opportunity to define a ubiquitous language which is business domain specific and spoken across the whole of the organisation.


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

This is the canvas your office walls are missing...

... just in case you read my previous post on the Dutch excellence in IT Architecture; No this is not a post about Rembrandt or Van Gogh. If anything, it's close to Mondriaan. The canvas I'm talking about is the Business Model Canvas, a Swiss invention in case you were wondering, made by Alexander Osterwalder. Both the Business Model Canvas and Alexander Osterwalder are featured on Wikipedia. Okay, here's a little trivia. Alexander Osterwalder was born in 1974 in the Swiss city Sankt Gallen. Fact is that I lived in St. Gallen 20 years later, when I did my internship at a Swiss company while studying Computer Science at a Dutch polytechnic. Coincidence? Maybe, but maybe it was ... well don't let me get there.

The importance of the BMC is that it allows people to make the right decision when they need to prioritise their pending activities. This is why you need to print it out poster-size and make sure that everybody in the organisation can at all times take a look at it from their desk. The BMC should be ingrained into your organisation!


So, the BMC. I think it's probably the most important model you as an architect can work on with your team and than print it out and give it a triple A location on a wall in your office. Printed such that everybody can see what's on it from any angle. And just in case your office has more than one room, make sure you print one for every room.
Just so your organisation's mission doesn't get lost, print it on the same poster above the BMC. Oh, by the way, you can also ask your management, your CEO, your board of directors, to give you the canvas so you don't have to create it yourself.

The reason for the importance of the BMC is that it very clearly documents why you're doing all that you're doing. And if you can't explain why you're doing what you're doing by means of the BMC, stop doing it.
The magic of the Business Model Canvas is that it helps you, initially, to write down what you think your business is. Business here is meant in the broadest sense of the word, so even when you're in an NGO, a not-for-profit, some form of governmental organisation or a commercial business, the BMC is crucial, especially the activity of filling the BMC. It should be your primary source of focus.
What is the BMC? Without trying to go too deep into the topic, here's a little extremely short primer. Do a quick Google or Bing search to find out more about the BMC.

The BMC has 9 fields that are desperate to be filled with your input. They're divided horizontally as well as vertically. Horizontally you see on the bottom the money flows, what's coming in, Revenue Streams, and what's going out, Costs. On the top you'll find 7 fields that correspond to your organisation, they explain all about the 'why' of the money flows. Who's your customer, who are your partners, what's your product, etc.
The vertically there's a split right in the middle. In the middle you find your product, what ever that may be, it even may be a service. On the left you find everything need to create that product or to deliver that service. Notice that this is on top of your costs, since input for product creation or service delivery requires payments, i.e. costs.
On the right you find everything that is needed to create a revenue stream through your product or service. Customers, channels through which to sell and of course customer relations to keep customers happy and invite them to purchase more.

As you can now see, every aspect of your organisation and it's (business) value is captured in one model. You should read about my view on models, which you can find here. The reason to read my view, is to understand why I'm a bit hesitant when talking about models. But also to understand that the BMC, which is a visualisation of your business model, is one of the best models out there because it so clearly defines what single aspect of a business or organisation it visualises.
Anyway, having a BMC allows you to ensure that your activities are related to what your organisation attempts to achieve, being creating value that is sustainable and in line with your organisation's mission and vision and is according to it's strategy to realise this vision. Say what? I need to formulate a mission and a vision as well and come up with a strategy? Well, uhm, uh, duh! I would be worried if you hadn't done so already. So I'm assuming that you have, giving you the benefit of the doubt.

One very practical way of filling in the BMC is to gather everybody from the management team in a single room and do a 3rd third workshop.
The complete management team should be in the workshop because they need to not only understand what the business model is, but also why it is the way it is. And understand everybody's input. Furthermore, all areas are related to each other.
When you're in a startup, this workshop can be with just the founders, or maybe when you're really at the early stages, it's just you. In a larger or more established organisation or if you're catching up with the BMC, you should involve all of the MT team, or maybe the members of the board. Just get all the executives in the room to do the workshop.
With respect to the BMC, limit yourself to the upper 5 fields and address them one by one. Take a full day, limit the total time for each field to 60 minutes. And make sure that you have a healthy refreshing lunch and a nice diner afterwards.

That's the recipe for a BMC, but what of it? What you'll notice is that when you work on the BMC, even without the 3rd third approach, some of the fields are easy to give some content, and some seem almost impossible. Now forget about the first category. I'm sure you'll manage. Heck, you'll be probably in need of restraints to keep you from talking about it. Focus on the hard ones, that's where you'll be able to gain the most from the BMC.
Typically the easiest is the Value Proposition, especially when you're a startup. When you're an established organisation you might find that one harder to do because you've diversified your business, and possibly too much.

I would say that you need to focus on your customers first. And make sure you've got some names of people you can contact. A good way to address this is to come up with a sample group of 5% - 10% of your customer segment that you can contact directly. When your market is smaller than 500 customers, consider the lower end of the 5-10%, when your market is larger... you get the drift.
These are the customers that you'll use to validate the rest of your BMC.
Now first validate your value proposition with your customers, use your sample to do so. Chances are your customers don't think your product or service will help them (optimally) or are not willing to pay for it or something else. There's a ton of ways to do this. Interview them, have them sign-up for a pre-order, start a Kickstarter campaign, etc. The point is that you need to make sure that your value proposition is feasible to pursue. And now keep on listening to your customers and keep them informed. And after reading this, you also know without me telling, that you need to make sure that your contacts will provide reliable feedback. You're building your BMC and therefore your business on their feedback. And before I forget, make sure that your vision and strategy are also taking this feedback into account.
Once you've got your customers and your value proposition filled, it's time to do that workshop and fill in the other fields. Make sure that they're in line with your customers and your product. But also make sure that they're in line with your mission and your vision. And strategy of course.

Which takes me to the lower half of the BMC, the money flows and how to address them. You'll need to make sure that you know how to make money from your product, or rather what determines your income. And you need to know where your costs are coming from as well.

The importance of the BMC is that it allows people to make the right decision when they need to prioritise their pending activities. This is why you need to print it out poster-size and make sure that everybody in the organisation can at all times take a look at it from their desk. The BMC should be ingrained into your organisation! It also means that the BMC has to be communicated to everybody. There shouldn't be anything secret about the BMC. When it is, you're screwed because you need to take a very dictatorial management approach with micro management. And if you take that approach you won't have time to generate your revenue streams to cover your costs. Think about it, it's one sheet of paper, what secrets can you fit on one sheet of paper anyway?

So you want everybody in your company to know what your business is, and how you think it can be sustainable. It will allow everybody to evaluate whether their actions are helping the business, create business value, or not.
And it goes beyond this, think about new product development or new features to existing products? Just one look and discussions about wether or not to do it can be rendered irrelevant. Marketing campaigns? Whether or not to do them is written on the BMC. Deciding about whether or not to partner with somebody? It's in the BMC.

This leaves me with my final comment about the Business Model Canvas; It is a model that needs to be revised, once every so often you need to reconsider its contents. Do it periodically, once every 6 or 12 months, but also do it when you've come to a pivot-point and realise you need to adjust your strategy, your vision or maybe even your mission. So make sure that you will maintain your BMC to keep its relevance.

I think all the above make sense, if not drop a comment and tell me what's not making sense to you. But if it makes sense, why do I hardly see a BMC print-out on the walls of offices? Why is it that so often there's no business model canvas even made? Probably there're three explanations.

• The existence or validity of the Business Model Canvas is unknown.
• It is considered too hard or too confrontational.
• It is considered a management only thing.

Whatever the reason is, you've come this far, now understand what it is and that it is beneficiary for the complete organisation. And it isn't that hard to create this most important canvas for your office walls. In addition, the canvas helps you to create a sustainable 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.

Arc-E-Tect

PS: Here's an interesting link to a more elaborate BMC picture.

[Special thanks to my amazing wife, who took the time to not only read the post but to also send me a Whatsapp with a whole list of corrections the post needed. Thanks dear.]