The Power of Accountability

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

Summarising

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

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

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

RACI explained

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

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

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

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

RACI for the Architecture

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

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

Who da man?

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

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

RACI to solve problems

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

Accept the Challenge

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

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

Arc-E-Tect

ASAS2017 in hindsight

ASAS2017 in hindsight

A couple of days ago, Thursday October 5th to be exact, I attended ASAS2017. It was my fifth attendance of the Agile Software Architecture Symposium.

Summarising

This year, as part of keeping a promise, I did a presentation at ASAS 2017 about Agile and Architecting. Adapting the presentation up to the last minute based on feedback I garnered while attending other presentations, I felt really agile.
One of the key take aways for me was that doing a Kahoot! to know the audience instead of raising hands makes a lot of sense when you want to know who your audience was. But you need to keep those stats. And it's almost imperative to have a clear means of being contacted shown on a slide. At the end.

A couple of days ago, Thursday October 5th to be exact, I attended ASAS2017. It was my fifth attendance of the Agile Software Architecture Symposium. This time around I was one of the speakers. It was a promise I made last year to the organizers. The promise was that if 2017 would have an ASAS, I would submit a proposal for a talk and if it would happen as such, I would be one of the speakers at ASAS 2017. Promises are there to keep, so I kept my promise.

Funny part, although at the time I really didn't think it funny, is that just days before my family and I would drive to Croatia for our summer vacation I checked when in November ASAS would be this year. Yup, I was mistaken by a month and the date was instead of somewhere in November, some time early October. The 5th to be exact. And apart from my submission in early April this year, I had nothing prepared at that time.

The topic of my talk would be something about architects being able to survive in an agile world. Something I am talking about almost on a daily basis with clients and especially their architects and agile coaches. But since April I had changed my story continuously... based on the feedback I got during those discussions. Understanding what works and what doesn't is important and crucial when you're coaching. So it was more or less imperative that the contents of the talk would be significantly different when compared to my initial view on the matter in March and the presentation I would give on the 5th of October.
Just to give you a hint, this is what I proposed in April:

How architects can be successfully agile.

Summary: Architects are known for their talent to ensure that projects run out of budget or out of time. The best of architects are successful in ensuring that projects run out of both time and budget. But with the advent of agile practices and the agile manifest, architects are no longer needed, they have no longer a role in continuously postponing a project and ensuring that tons of money are wasted. With waterfall becoming water under the bridge, there is no longer a need for procrastination by the architect. Unfortunately, as evolution goes, architects are genetically inspired to build ivory towers. Doomed to follow the path of the dinosaur. Unless... unless they manage to become agile. This session is about how architects can become agile and thrive again, gaining the respect of... well pretty much everybody and their mother.

When I set off on this journey, I figured I would talk about architects and how they need to change their attitude and way of working. But over the course of the months since April I realized more and more that it's not the architect that needs to change, so I adapted and changed my presentation.
In fact I changed my presentation even 10 minutes before I had to go on stage and give it. Truth be said that in those final minutes the changes weren't significant, yet they were adaptations to feedback I got while attending other presentations that day.

I started of with a Kahoot! to get to know my audience. Instant feedback in terms of laughs meant to me that it was a good way to break the ice... but since I forgot to save the results and in the first place to test the quiz myself, meant that I don't have the right metrics to judge the appropriateness of my slides.

I ended with the opportunity for my audience to ask questions. And that was when the room stayed quiet. Silence. No questions. Not a captivating story that was raising questions. Until a question was asked. By one of the Arc-E-Tect blog followers. There was the answer, and that's when the questions came. And people stayed afterwards, wanting to know more. And then there was the after-party and more people wanted to discuss the presentation.

So in hindsight, the presentation went well. It went well considering the metrics I had set for myself up front. How many people would be in the room, how many would leave during the presentation, how many would join the Kahoot and how many questions would be asked during the presentation. And finally how many would want to talk about the topic after the presentation was done and they had ample opportunity to talk about other things to other people. In all cases it was beyond expectations.
Considering my expectations; the Kahoot! was about getting around 75% of the audience to join, which I think was achieved. I don't have numbers about the audience. Considering people leaving the room during the presentation, I only saw 2 persons leave in a room of about 50 people. Considering questions asked, 3 questions was for me the minimum, based on the fact that I thought I would have time to spare for questions and the story was compelling. 4 questions were asked with 4 different persons asking more questions.

All in all I feel that my presentation at ASAS 2017 was a success, also as an experiment to see if you can consider a presentation to be a product that adds value and can be done in an agile way. 

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

You know you're the Product Owner...

...when your product's users are complaining and you have to worry about your bonus.

Summarising

The Product Owner's bonus is on the line when users complain! You're not worried about the upcoming appraisals although the users are complaining? And you're not looking for that boat you fancied for so long because the users are giving you great reviews all the time? You're not a Product Owner.

In this day and age of DevOps and Agile, the most coveted job in the world seems to be the one of Product Owner. Never have I seen so many co-workers turn into a PO as recently is the case. Operators turning into Operations PO, testers turning into the Testing PO, security experts fulfilling the role of Security PO. It's amazing to see all these Product Owners mushrooming in organisations.

Understandably, because their original jobs are nearing their expiration date, or so they're let to believe.

The other day I had an interesting discussion with one of the architects of a client of mine. We're discussing a lot these days about architecture, API's, services, data warehouses and other interesting stuff. But this time around he challenged me. Seriously.

This particular client is a typical Project oriented organisation. Projects develop something and once it goes into production and becomes at times business critical, a very efficient department takes over. (Just in case you're wondering why I put efficient in italics, read this post). This architect is part of a department that is making the transition from a Project oriented towards a Product oriented way of working. It's a significant move and absolutely not trivial.

What's interesting is that the general understanding of the necessity of a mandated Product Owner has caught on with this client of mine. What hasn't caught on is that the PO is supposed to be somebody from the business. Take this with a tiny grain of salt thought, as by stating that the PO needs to be a business person, I mean that the PO needs to understands the business in which his products make a difference and generate value. Do you need to be an MBA? Nope, but you do need to understand the relevance of the product for your user.
And this is exactly the issue at hand. All the different so called PO's my friend the architect is dealing with do talk with the user, but do not necessarily understand the relevance of the products they're using. The Operations PO discusses the stability of the product, which makes perfect sense because the focus of an operations person is ensuring that the product is not crashing. One could argue that the relevance of an operations person is the fact that products will crash, which is a bit ironic. The Testing PO is of course focusing on whether or not the product is conforming to the requirements and specifications. This is what testing is all about: Is what has been build, delivering what was intended in the first place. And with all the security incidents, global incidents at that. And with all the new laws and regulations around privacy and what not, the role of the Security PO is cut out, it's focusing on limiting the risks for the organisation by having the products being used by, well the users.

Since all these PO's are doing their job extremely well, the products are up to par and are in fact creating value for the organisation. They surely do. But that is not to the credit of these PO's. The reason for this, is that none of the PO's are concerned with the best product, i.e. the product that is helping the user to conduct business. They are all focused on the product delivering what was intended, namely stability, requirements and security.
I hear your brains churning on this, so let's make an assumption here to illustrate: What if the product crashes all the time, but when it doesn't it removes the hassle of manual steps in a complex process? And although it crashes, data integrity is guaranteed? The operations person won't like it and will very likely take the product out of commission. Why? Because operations is affected when stability is an issue.
So now it turns out that the product is fully according to spec, tests are 100% green but the user will not stop complaining because the product is still not helping to drive business? The tester will not look into this as a testing issue, but as a specification issue. The fact that the tests didn't reveal this major flaw, namely usability. And even when it did, usability being a testable requirement is a novelty. It is with my client's organisation and it is in many others.
Guess you can fill in the problem with the Security officer acting as PO. Consider it a small exercise to flood your brain with some endorphin.

The issue here is that none of these so called PO's is accountable for the success (or failure) of the product. None of them is. And this is what sets the PO apart from everybody else in the organisation:

The PO's bonus is on the line when users complain!

This means that when a accountability of a product's success, i.e. the level if complaints from users about the product, is not with you, you're not the Product Owner. It also means that unless you get a full mandate to make a success out of a product, you're not the Product Owner either.
Don't accept the role of PO unless you get full mandate, which includes discretionary say about the product team, its road-map, funding, etc.

Back to our wannabe PO's, because that's the correct word for them. Their bonus is not on the line, they're not responsible for the product's success. They're definitely not accountable. But that doesn't mean that they're not responsible for making the product a success. Their knowledge, insights, experience and general professional view on the product is invaluable input to the PO to create a success out of a product. The PO shouldn't ask for their input, but when the input is not provided, the questions should be raised. They're not impacted by bad reviews, the PO is. They do have to worry about their jobs, because if the PO can't use them...

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

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.]

This is why the Dutch make the best Chief Architects...

Summary

Last Wednesday the Dutch had to perform their civic duty and vote. You may or may not have read about it, but it inspired me to post about why the Dutch make such awesome IT architects, and why your Chief Architect should be Dutch.
Having a Dutch Chief Architect, or even just architects, in your organisation will ensure that there's going to be synergy. That you'll be able to benefit from something like a collective mind. That you will have a strong person that is able to bridge gaps in culture and break through language barriers.

Why the Dutch are the best architects out there...

... Last Wednesday the Dutch had to perform their civic duty and vote. You may or may not have read about it, but it inspired me to post about why the Dutch make such awesome IT architects, and why your Chief Architect should be Dutch.

I could end my post right there, because I mean, it's obvious isn't it? But just in case you're not too familiar with the Dutch let me explain.

First of all, architecture and being an architect is all about communication. It's about explaining what you want to achieve and why you want to achieve it. And the trick here is that the architect needs to ensure that there's buy in throughout the organisation in such a way that everybody is not only on board, but also convinced that it is the right direction in which the architect wants them to move.
The Dutch do this by nature. It's an essential part in the Dutch culture to work together and get onto common ground. The Dutch call it "Polderen". It's a Dutch trait, and only the Dutch know how to do it.
Here's the deal, with the latest election results, it's very thinkable that it will take up to 4 different political parties to form a coalition that has a majority in the parliament. And the Dutch are not worried at all, because we're confident that although the different factions have very different believes, they will be able to work something out and rule the country. Form a government.

What the Dutch can do as part of their culture, an Enterprise Architect, and a Chief Architect ever so more, will need to do as part of their role. Get common ground, work with different powers within an organisation and ensure that the whole of the organisation will achieve its goals, meet its objectives, work together to implement the strategy. Who better than a Dutch architect is most suitable to perform this Herculean task?

But wait, there's more!

Chances are that when your organisation has enterprise architects and a Chief Architect, your organisation will be fairly large and will have employees, vendors and customers from all kinds of backgrounds. Could be different ethnic backgrounds, different religions, different nationalities, different everything. Working with all these different people with different views, cultures, languages, etc. will be a challenge.
Again, the Dutch will be able to fit in immediately and work with them all. For one, the Dutch speak a variety of different languages. Of course they'll speak Dutch, but English will be there covered as well. And very likely they'll speak German and French as well. More and more Dutch children learn how to speak Spanish or Chinese in school. But on a linguistic level, you're covered when you're dealing with the Dutch. In addition, hardly any of the TV shows are dubbed, instead they're subtitled, so you can be sure that that Dutch architect you're now thinking about will understand the nuances of your languages, a fair amount of slang and sayings.

What's more, ever since the Catholic church started killing people because they didn't agree with how the Pope thought how life had to be lived, the Dutch took in those that fled from the Catholic raids and Inquisition. And more importantly, the Dutch embraced all these different nationalities, religions and cultures as part of the Dutch society. Not always without a fight or without amendments, but nevertheless, Dutch culture is to embrace other cultures.
Now think about different cultures within your organisation. For one you most likely deal with employees from all over the world, or at least different religions, upbringings and the like. But there's more. You must have noticed that those people from accounting think rather differently from them from legal, and the sales people are slightly different then the people working in IT. Still in IT itself you've got the developers and the operators that are different. However you look at it, you need somebody at the helm that you can trust with knowing how to deal with different cultures, mindsets, objectives, manners, languages and vocabularies. Who else than the Dutch architect can take this task upon himself?

Obviously the architect is all by himself, even when he's the Chief Architect, he'll be the minority. He'll be the few among the many. Heavily outnumbered. Under normal conditions, that might be a problem, but not when that Chief Architect is Dutch.
The reasoning behind this statement is quite simple. The Dutch know how to rule the world. Until not that long ago they ruled together with the British the Seven Seas. They, the Dutch that is, managed to become a global player although massively outnumbered.

Finally, the Dutch don't take anything for granted, but more importantly, they're a people that don't take just anything at face value. Instead of just mindlessly following orders, the Dutch will use their head and will stubbornly refuse to do something that doesn't make sense.

Having a Dutch Chief Architect, or even just architects, in your organisation will ensure that there's going to be synergy. That you'll be able to benefit from something like a collective mind. That you will have a strong person that is able to bridge gaps in culture and break through language barriers.

So yes, I think it's clear. The Dutch do make the best Chief Architects.

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

"We develop our frontends in Angular" is not an Architecture Principle

Did you ever hear that story about that architect who was telling the developers how to develop their solution? Badabing, badaboom!!!

Yeah, I know it’s a bad joke, there’s no laughter there. I better not aspire a job as a standup comedian. Thing is though that there’re still plenty architects out there that are not only defining architectures, but also tell the developers how to develop that architecture. It amazes me why this is the case.

I know that not that long ago I told you to ditch your architects when they are busy creating roadmaps. But actually you shouldn’t because there’s a real legitimate reason for defining roadmaps. The reason being that they’re an excellent tool. So ditch the architect when roadmaps are what they deliver, because those are the ones you want to get rid of.

Now there’s another breed of architects out there that I have a hard time to understand. I really think that architects should be architecting. That’s what their roles are, just like developers should develop. People should be doing what they’re supposed to do, and preferably spend some time outside their boxes while thinking about what their job really is.

For an architect, the sole raison d’etre is to have answers when asked questions and at the same time be enigmatic. Well, maybe that last part should translate into being helpful to whoever is asking the questions to get the answers themselves.

The architect, as I see it, is the one that defines the boundaries within which the developers can act freely while being confident that there’s no harm to the overall integrity of the enterprise or the organization for that matter. The strength of the architect, the real power, is that this can be done by defining Architecture Principles. These are extremely powerful because you can link them directly to your organisation’s mission, vision and strategy. Well if you can’t than you should reconsider your principles. But if you can, you’ve got your business justification for your principles and you won’t need to define the business value of those principles either. But just like any power-tool, they’re not trivial and to formulate the right principles you really need to be ready to spend some serious time. Furthermore, you need to limit the amount or principles to a maximum of 10, just like the 10 commandments. More will be hard to remember by heart and live by, which is what you should expect from your developers. Less is better, but beware of the fact that you should cover all the important bases in your environment.

There’s another tool that’s really powerful, which is the reference architecture. Which in fact is a model, one of the good kind as you can read here. A reference architecture is a model of an application that meets all the architecture principles. But beware; It’s a model, not an architecture! It’s a visualization of what the architect had in mind when he defined the set of architecture principles. And more importantly, it’s one of many possible models.

So as the architect defining the reference architecture you should be aware that everything in it, can, should and will be taken with a grain of salt. And as the developer you should understand that the reference architecture is just a tool for your architect to illustrate what was meant by the architecture principles, and definitely should not be taken literally.

Ah, so what about the joke, the bad one?

Well, there’s this group of architects that don’t understand the difference between architectures and models and instead of defining architecture principles and reference architectures, they tell the developers what and how to develop such that they comply with the principles.

There’re some serious problems here. For one, the architect omits the definition of architecture principles for whatever reason. Likely because it’s too hard, or they don’t see the benefit. Shame on them! Then there’s the case where the architect ignores the fact that the developers are very likely more proficient in developing than the architect. Oh, and let’s not forget about the fact that architecture principles are almost timeless, or at least stick around quite a bit longer than the typical technology, tool or framework. Yet, this architect dismisses this simple fact of IT and at the same time doesn’t keep the construction manual, because that’s what it is, in line with the current state of IT affairs.

For example, I discussed a couple of years ago, where ‘discussed’ is a euphemism for ‘verbal fighting’ with some fellow architects in some kind of architecture board that it made no sense to dictate that a multi-tier architecture should always be deployed such that each tier should be on separate infrastructure. Instead the application should be complying to the fact that data access logic not to be mixed with business logic nor with presentation software. Sometime ago I had a discussion, which was a real discussion, about whether or not we should define in reference architecture that either Eclipse or Visual Studio should be used for coding. Uhm, I think not, thank you very much. And yes, this was a real discussion.

There’s the discussion about what part of an application is developed in what programming language? We had the discussion at a startup I was Chief Architect at. Guess what, the developers made those decisions, I just stated the principles that I wanted them to comply with.

So what it actually boils down to is that architects need to govern, and that should take up most of their time. They should safeguard the integrity of an organisation’s IT landscape and make sure that in all cases the applications or rather the products in that landscape can comply with the architecture principles. The architect should promote and facilitate an unambiguous way of working among teams. The architect should also be concerned about an ubiquitous vocabulary within the organization when it comes to business and that it is translated by IT consistently.

The architect should not dictate that a particular programming language to be used, that a particular infrastructure is to be deployed to or that specific tooling is to be used. And in those cases where there’s a good reason for the architect to do this anyway, than it should be implied instead of explicitly dictated. In case all development is to be done in Java, the architect should ensure that only Java developers to be hired. In case everything should be hosted on Amazon AWS, the architect will have to pave the way for the teams to use Amazon AWS, making it the favorable option for the teams of the many hosting alternatives they can choose from.

As you might have guessed here, is that the architect I’m referring at is the enterprise architect or domain architect. Definitely not the application architect or the solution architect. The latter are both very much there to device a solution for a problem. They’re more like designers than architects in that sense. Which brings me to another little piece of personal amazement. Why are there so many large organisations that have domain architects on enterprise level whose domain has nothing to do with the business, but are strictly technical? Probably this is some remnant from the time that we considered IT to be a cost center and centralization of IT was the holy grail for many a CIO. Nowadays where we see IT as a product, something that is not just setting us apart from the competition but an actual product, there’s hardly any room for the these architects, at least not on an enterprise level. They should be working closely with products teams from the same product portfolio. Become Product Portfolio Architects, safeguarding the integrity of the IT landscape of the portfolio. Is it a demotion? Definitely not, it just means that they’re relevant again.

To paint a little context here, I’ve been that architect I’m complaining about. Emphasis on ‘been’. I enjoyed the technology too much to let it go, but as the domain architect I wasn’t allowed to work on the software, so all I had was telling the developers what to type. Initially I got away with it, because I was at least one of those architects that actually could still code. But really soon thereafter it became apparent that I hardly had enough knowledge or experience to really do the work. To me that was a real eye opener and I had to good fortune I was working with people that didn't hide the truth from me. They expertly conveyed to me that yes I was more than a decent architect, but as a programmer I really wasn't up to it anymore. And as much as that hurt at the time, it allowed me to focus on architecting. I still code, because I still think I need to be able to understand and to know that things might work. But as an architect, especially in an agile world I find myself more and more facilitating, communicating and coaching. Working 3 sprints ahead of the developers, not because I'm that a fast thinker, but because being an architect I need to be able to set directions. Let the team worry about how to get to our destination, be their own satnav system, and me the architect am more and more the person controlling the system's settings. Controlling whether or not to allow ferries, toll roads, to prefer back roads, go for the scenic route or the fastest or most economic route.

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