Digital Transformation to Survive in '19

This is a cross-post from an article I published on LinkedIn.
Today I came across a quote and realised the enormity of it. The quote inspired me to write this article. It is an excerpt of some preliminary text from the book I started writing in late 2017 and am still working on while typing this article. A book for which I am still trying to find an appropriate working title.

“If the rate of change on the outside exceeds the rate of change on the inside, the end is near.” - Jack Welch

The enormity of this quote is in the fact that unless an organisation can adapt to a changing world, one that is changing at an ever increasing rate, the organisation is doomed to seize to existing. Having worked with and still working in organisations that are realising that change is needed in order to survive, especially in the long run. I often encounter leadership that is acting more like a 'management-team' than a 'group of leaders' welcoming change and promote that change. A core cause of problems when implementing the required changes.

Finances to drive change

These organisations financial outlook typically show the necessity of change, but all too often those same finances insufficiently show the required pace in order for that organisation to survive.

The change I am referring to is often initiated under the name 'Digital Transformation'. A transformation many organisations find themselves in. Unfortunately, it is often met by the organisation's cynicism as it is perceived as yet another restructuring project. And in more cases than not, rightfully so. Any organisation that is looking for a sustainable means of staying competitive, will need to be able to continuously reinvent itself. It will need to adopt a practice of continuous change. As it is the only way to become more capable than the competition and excel on a never levelled playing field.

Understanding this need to adopt a mindset where 'to last' is replaced by 'for change' in the organisation's DNA, is the key to find the right sense of urgency. A sense of urgency that is a pre-requisite for a successful digital transformation.

Not just your average Agile Transformation

The 'Digital Transformation' is more than just an 'Agile Transformation', which typically takes place in the IT department. The agile transformation is limiting itself to a different way of working. Ranging from adopting an iterative approach in software development to empowering the team that develops the software also support the application in a production environment; DevOps. Embracing the build-measure-learn paradigm, these teams are not so much 'more efficient', instead they are 'more effective'. Increased effectiveness results in a reduced risk of 'bad investments'. It means being better able to act 'just-in-time'. This also increases the opportunity to be more efficient. And it is efficiency that leads to more productivity. 'More for the same' instead of 'the same for less'.

A digital transformation is one that impacts the full organisation, not just the IT department. It allows the organisation to leverage (new) technology to be more effective. Applying technology to increase effectiveness of an organisation. Improving the organisation's sustainability is what defines the difference between future success and future failure. The reason for this is that increased effectiveness allows an organisation to change at a higher rate 'on the inside' than it experiences change 'on the outside'. A prerequisite of surviving in the long run in a competitive market.

The full story

Shorter product development cycles, a typical objective of agile transformations, are only a tiny part of the full story. An essential part, but tiny in comparison to what else is needed. A digital transformation encompasses the restructuring of an organisation. With the intention to establish change (over time) organically. Change that allows the organisation to grow, or shrink, as required. One that as a trait, constantly reduces the 'chain-of-command' to its bare minimum. One that embeds 'build-measure-learn' in its core processes and where its leadership relentlessly applies fact-based decision making. Where measures of success are defined at the start of every initiative and that continuously searches for means to reduce the risk of 'not knowing'.

Although the transformation is mainly one that impacts the organisation and its processes. It is a transformation that almost religiously relies on the (digital) technology available in the market. Cloud, AI, Data Analytics etc allow us to work with all relevant information (facts) at our fingertips. But the introduction of these technologies are not what makes the digital transformation such a challenge. Harnessing them is. And since we are at the start of the evolution of these technologies, being able to change with them. As the new techhnologies become ever more sophisticated and powerful, they will set the boys apart from the men. But mind you, it will most likely be the boys that will come out on top.

Concluding

The digital transformation, therefore, is one that transforms an organisation from a mindset of 'to-last' to a mindset of 'for-change'. From one that finds its future in a foundation of bedrock, to one that finds it future in being able to surf the waves. Traditional stability is focused on not having to change in a changing world, whereas adaptability is focused on being able to change with a changing world.



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


This article is reflecting my own, personal, opinion and does not reflect in any way the views, ideas or opinions of any organisation I work or worked for. It is based on my own personal experiences and research I conducted by myself.

How Charming is Laziness?

Long time ago, while I was still a student at the PolyTechnic in Enschede, The Netherlands, I would justify my choice to study computer science, by proclaiming that laziness leads to efficiency. Which of course makes no sense I now know, because it leads to effectiveness. Penny-pinching leads to efficiency. You can read all about it in this post Perish or Survive, or being Efficient vs being Effective. But there's this little concept that results in more efficiency and laziness as well. It's therefore a charm. It is called automation and closely related to that third time.

Third Time Is Automated Principle

One of the key principles at Amazon AWS is that everything must be automated. It's not just that everything should be automatable, but it should be automated.

Whether or not it's an urban legend, but word has it that when you create something that requires manual action, you're out looking for a new job. For a company like Amazon AWS it is clear why automation is such a huge thing. And it is clear as well why they have such focus on API's. API's are how automation across the board is facilitated. But most companies are not Amazon or any of the other cloud providers. Most of you my dear readers are more likely to run your systems on Amazon AWS, Google Cloud or Microsoft Azure, then run those applications for your customers. Probably, your IT landscape is in size not even close to Amazon. Probably comparing to Amazon AWS as the Netherlands compares to the rest of the EU. In most if not all of the dimensions you can think of.

Arguably, the principle of "Automate Everything" doesn't apply to you. I'll leave it up to you to think of one or more arguments why automation is not something you should hold dearly.

Challenge to you: put in the comments a good reason why you think automation is not necessarily needed. I'll make an effort to counter your argumentation as a reply to your comment.
But read on first.

The benefits of automating processes are many. Irrespective of the kind of processes. An automated process is infinitely more likely to be repeatable than any manual process. This results in higher quality since errors will either be made consistently, and can be fixed, or will consistently not occur at all. How compelling is that?
Although the automated and manual version of a process might take the same amount of time to be executed, the automated process allows a person to work concurrently on something else that cannot be automated. And automated processes do not rely on the availability of a specialist to execute the process. So automation makes you and your organisation more scalable.

Not automating processes, even IT processes doesn't make sense. Still, when it comes to IT, we hardly do this. Why?

The situation at Amazon

I've come across many situations where things weren't automated. Worse yet, they could be automated. They were not automatable.

For me this was always an interesting fact to find out. For one, we're in IT and IT is all about automation. In fact, in Dutch we refer to IT as Automation (Automatisering - Dutch). The paradox is that we apply IT all over the enterprise to automate business processes, but when it comes to the IT processes themselves, automation is very likely the last thing on our minds. And when you think of it, that doesn't make sense at all. Walk into a room full of IT people, and just pose the statement that it is hard to understand why we're so good at automating business processes, yet we don't have automation in our own processes. And you'll see at least 90% of in-agreement-nodding heads, the remaining 10% are too flabbergasted with the realisation that this is a true statement. Same statement in a room full of non IT people and the first thing you find yourself doing is explaining why this is.

The fact that IT people are not automating their own processes is tough to explain, and I for one do not have such an explanation. There is an explanation though, for why Amazon AWS's processes are all automated. It's because one of the core principles by which they do IT is "Automate Everything". At a dinner party with Werner Vogels (Amazon's CTO) I was invited to, being the Chief Architect of a FinTech startup, I asked Werner (all attendees were told that we were on first-name basis), how it was possible for a huge company like Amazon AWS to live by these rigorous principles. Everything is an API, Automate Everything, and a few more. His reply was that there were two main reasons why it works. 

1. Senior management all the way up to Jeff Bezos, were openly behind these principles. In fact many of them were mandated by Jeff Bezos himself. 
2. Everybody in the organisation experienced for themselves the validity of these principles.

I asked him to clarify that second reason. According to Werner Vogels, Amazon is dedicating a lot if not all of its time to make its processes impacting customer experience as efficient as possible without impacting customer satisfaction. 'A satisfied customer is a returning customer'. The effects of changing a process is made visible to the whole company, at all times. So compliance to the principles will result in changes to the processes and the effects would be visible. Therefore, the validation of the principles would be continuous. And according to Werner, nothing is as motivating to change your processes than to see the effects of your efforts.

Rest of the dinner I was milling this over, enjoying the food and talk to the other guests.

The situation in the 'real world'

Unfortunately, most of us work at real enterprises. And those two reasons Werner Vogels had given me why IT process automation worked for Amazon aren't obvious in the situations I have found myself in.

For example, the amount of automation in a process within IT is not a metric that anybody is held accountable for anywhere I've worked or consulted. Neither are the benefits of automation part of somebody's accountability.

IT process cost reduction (IPCR) is as far as I know not a KPI within enterprises. Nor is the time-to-market (TTM). The latter often does find itself in another incarnation on reports and dashboards, namely as MTTR, the Mean Time To Resolution. When it comes to MTTR, we do see them on reports, but the MTTR is in hardly any case part of somebody's accountability. Same goes for time-to-market. Although it is always mentioned for any improvement project, it is hardly measured or reported on. It's a project issue in most cases, meaning that an organisation is doing projects instead of delivering products.

The lack of real metrics and if you will KPI's means that from an accountability perspective, there is not a clear person that has an incentive to push automation. And if you read my blogs on a regular basis, you know that I'm big on accountability.
Visibility of the effects of changes to the IT processes is another challenge for organisations. We often find ourselves in organisations that don't have a culture to measure our IT processes. This is especially true for organisations that have been around for decades. Since IT process automation is not pushed, there is no incentive to find bottlenecks in processes or pinpoint areas that are up for improvement. Resulting in the situation where the effect of improvements are not visible in most cases.

The lack of accountability and the rather big hurdle to be taken by IT departments in order to automate result in a situation in which we are just not automating our processes, because it gets no priority on our backlogs or funding in our PRINCE2 budgets. Process automation is collateral. And it's not a matter of not being as large a company as Amazon. It's a matter of not being aware of how automation affects the bottomline. And of not being held accountable for impacting the bottomline.

Third Time Principle

Three times is a charm, or at least should be automated.

In organisations I worked previously, the principle of automation as in play at Amazon was a little bit more pragmatic. One that has worked well for me, is the principle of "Everything done a third time, will be automated", reasoning behind this is that if you do the same thing a third time, it is extremely likely you will do it a 4th, 5th and even more times. The time required to create the automation will be saved by executing the task over and over again.

Time invested is never gained, but can only lead to savings later on.

The Third Time Principle is a compromise, although one might argue that it is a Troyan horse. By adopting this principle, the argument that it creates too much overhead for mundane actions is off the table. Only those actions that are performed repeatedly are automated. Built in justification for the investment needed.

The Third Time Principle is easy to adopt. Since it is a compromise, it can be applied when the push to automation is bottom-up. We often see that engineers see the need for automation since that is where automation will solve a problem and effects are noticed. To develop the automation is often a matter of getting the time to do so. Automation is now competing with other requirements for development time, for priority on the backlog. We all know where the priorities will be. Applying The Third Time Principle will remove this obstacle. Engineers can justify the need for automation and the Product Owner can justify the priority of the automation stories on the backlog.

Continuous Delivery

When striving for Continuous Delivery (CD) and more so for Continuous Deployment (also CD), there is no other way than to automate everything. CD requires a rigorous regime to move every manual task to the left in a process defined western style (i.e. left to right notation). Product development follows the DTAP model. Development is followed by testing is followed by accepting is followed by production → DTAP. In CD we hold true to the paradigm that everything manual is done in D, and TAP are fully automated. Any manual action in T, A and P needs to be automated and the scripts for this are developed in D, because otherwise it can't be done.
So when striving for Continuous Delivery, everything in the product development cycle is to be automated.

Accountability

When process automation metrics are part of somebody's accountability, that person will also be mandated to automate as much as possible. This is for the simple reason that you can't hold somebody accountable for something they cannot influence. Therefore, when process automation is measured through some metric for which somebody is accountable, it is that person's prerogative to drop The Third Time Principle and instead adopt the Automate Everything Principle.

Accountability is a matter of top-down enforcement. It is also a key aspect of culture change. When we want to adopt a culture in which we allow ourselves to reap all benefits of automation, especially our IT processes, we can't get around the fact that we need to revisit the metrics by which we hold ourselves accountable.

Scalability

One aspect that I haven't really touched upon is scalability, although I did mention it briefly. Automation is a key aspect of scalability, not so much scalability on a technical level but organisational scalability. Manual actions always need a person to execute them. The more complex the activities become, the more experienced or knowledgeable the person needs to be. And before you know it, it requires a specific person within the organisation. Because you rely on this person, that person will become the person with all required knowledge, it's a vicious circle. Think about it for a second, and I'm sure that you can think of a process or an activity in a process where you rely on a specific person and you know that person by name. In fact, if you want the activity to be done, you will even call that person because she's among the busiest persons in the company.

When you want to keep activities simple, you need to automate them. The more you automate, the easier it is to keep the activity simple. Hardly anything is more simpler than to have a command like 'do_complex_activity.py' provided that the automation is done using Python. Anybody can run this command provided they have the rights to do so, and when done really properly, anybody can do it at any time, because all the complexity of who can do what when is taken care of by the automation code as well.

Concluding

In the end, you'll agree that automation is what we need to apply to all our processes. At least when it's the third time you're doing the same job. It will improve quality and consistency. It also means that we as a company can scale our organisation without the need to increase headcount. It will be important to monitor the benefits of automation, without metrics it will remain a matter of good faith on the short term, and it will not justify the investments on a longer term. By understanding the benefits of automation and getting insights on where automation has most impact.

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.

Cloud Native Enterprises - Broad network access

Which don't have a lot to do with Cloud Native Apps but everything with truely embracing the paradigm shifts the Cloud has brought IT within the realm of businesses.

Read the Introduction first.

After reading the introduction to these posts you know what a cloud infrastructure is and what cloud native applications are, what about cloud native enterprises. Well these are enterprises that adhere to these same 5 characteristics. These enterprises, or organisations in general, cannot be modelled according to traditional enterprise models because of their specific market, competition, growth-stage, etc. These enterprises need to be, for all accounts, be cloud native in order to grow, succeed and be sustainable. Interestingly, but not surprisingly they require The Cloud and Cloud Native Applications.
In coming posts I will address every essential characteristic of The Cloud as defined by NIST from a perspective of the Enterprise. Unlike most cases, I will post these within the next 7 days and I certainly do hope before coming weekend.

• On-demand self-service. When online services and core systems really seamlessly integrate.
• Resource pooling. When synergy across value chains makes the difference.
• Rapid elasticity. When business is extremely unpredictable.
• Measured services. When business resources are limited.

Broad network access. When your business hours are truly 24x7.

This is an interesting aspect of the Cloud Native Enterprise. Because many organisations are already 24x7 businesses. Especially in the online world, being always on is a requirement to stay in business. 

Network here is not referring to the the computer network on a technical level as we know it. According to NIST, one of the characteristics of the cloud is broad network access, which from the definition, this means that the cloud is always accessible through the internet. The computer communications network.
Within the context of the Cloud Native Enterprise I am referring to the communications network of the business. On the one side, this encompasses all parties a business has dealings with. Think customers, users. partner, employees etc. I will get back to this later on in this post. But it also encompasses all means through which this communication takes place. Think devices and associated channels.

So, when we look at the business that is truly cloud native, when we talk about broad network access, we mean that the business is accessible by its complete business network, via a variety of devices and channels.

The Cloud Native Enterprise exposes its services, all of its services, in the same way to customers as it will to users and partners, as well as employees. Every member of every group enjoys the same level of service and the same constraints. Distinctions are made using the concept of role-based access to services. Still all services are always accessible to all members of the network through the same channels. In addition, it will provide the same level of service through all channels on all devices. Ideally. Of course contextual limitations are to be taken into account.

Traditional Focus - Cost vs Value

Consider the more traditional enterprise, where customers are assigned a specific account manager. The account manager maintains the relationship with the customer. She has specific KPI's that need to be met and she is more or less free in determining how to achieve this. Users of the customer are not aware of the account manager, instead they interface through a help-desk with the enterprise which will consists of self-service functionality for the more mundane support, automated systems like chatbots and more complex interaction through a help-desk agent.
Partners of the enterprise on the other hand, will work with peers within the enterprise. Informal contacts are more prevalent and accepted. Where customers and users will need to follow the formal processes in order for the enterprise to be more efficient, partners will follow the informal communication lines in order to be more effective. We see in traditional enterprises that with customers and users, processes are cost driven. Partner oriented processes are value driven.

Cloud Native Focus - Revenue

In the Cloud Native Enterprise, all interactions are focusing on revenue. Key aspect here is the homogeneous approach towards interaction with stakeholders. Customers, employees, users, partners are all considered stakeholder of the enterprise. Access to the enterprise is homogeneous across the full network, and processes are optimised for revenue. Sometimes resulting in focus on efficiency, other times on effectiveness.

What you will see is that business scalability, both temporal and geographical, is addressed explicitly. Every stakeholder in the enterprise's network can access the enterprise 24x7 and from any location.

For every organisation this is a challenge to manage. But for the Cloud Native Enterprise the mere premise of the Cloud as an IT facilitator, it becomes a matter of survival.

Consistent User Experience

The Cloud is great for realising products and services that scale with your business. Not talking about elasticity here, but about the ability to have a single approach towards addressing your stakeholders' needs and demands.

Leveraging the characteristics of the Cloud, including its technical aspects of broad network access, means that it is possible to provide all users of all services and products with a consistent user experience. This entails the same experience provided to customers, partners, employees etc. This consistent user experience across all services will allow for a seamless transition for a user from one role to another.

Concluding

As with its technical counterpart, (broad) network access is a key characteristic for the Cloud Native Enterprise, as it will provide a homogeneous approach towards accessibility of products and services across the full breadth of the business network

(Special thanks to my colleague Mandeep for pointing out some much needed clarifications in the original post)

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.

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.

Cloud Native Enterprises - On-demand self-service

Which don't have a lot to do with Cloud Native Apps but everything with truely embracing the paradigm shifts the Cloud has brought IT within the realm of businesses.

Read the Introduction first.

After reading the introduction to these posts you know what a cloud infrastructure is and what cloud native applications are, what about cloud native enterprises. Well these are enterprises that adhere to these same 5 characteristics. These enterprises, or organisations in general, cannot be modelled according to traditional enterprise models because of their specific market, competition, growth-stage, etc. These enterprises need to be, for all accounts, be cloud native in order to grow, succeed and be sustainable. Interestingly, but not surprisingly they require The Cloud and Cloud Native Applications.
In coming posts I will address every essential characteristic of The Cloud as defined by NIST from a perspective of the Enterprise. Unlike most cases, I will post these within the next 7 days and I certainly do hope before coming weekend.

• Broad network access. When customers, partners and users are distinct groups treated equal.
• Resource pooling. When synergy across value chains makes the difference.
• Rapid elasticity. When business is extremely unpredictable.
• Measured services. When business resources are limited.

On-demand self-service. When online services and core systems really seamlessly integrate.

This is the post where I'll address the aspect of the On-demand Self-service. An aspect which for many organisations is rather challenging. Just like the aspect of Measured services, this aspect is addressing internal governance structures. Although the governance implications will touch on the financial governance of an enterprise, the challenge is more of an organisational nature and in fact  the financial parts are not always relevant.

In any case. When we talk about on-demand self-service within the context of Cloud Native Enterprises we talk about an enterprise where tools and technologies needed to explore or exploit business models can be obtained when needed, by the person that needs it. Often we talk about IT resources, software and or hardware. But think in terms of services, which are often IT services.

In a traditional environment, IT services are obtained by the IT department. This is where the IT experts are and this is where the required frameworks for 'proper IT' are defined and used. Business departments will request, based on functional specifications, certain IT solutions, experts within the IT department will make sure that the best solution for the lowest price will be procured, installed and configured. Hassle free operation for the business people as a result.

Traditionally the reason for an IT department is centralisation of these resources in order to make as efficient use of these experts as possible. Actually, what I most often see is that within IT departments there are separate teams for specific expertise, so called Competence Centres or Centres of Excellence. Efficiency has been a key objective for many years within organisations, often because IT resources (computers as well as personnel) were relative expensive compared to other resources.

As efficiency has been a key objective in these traditional environments, the scheme above played out nicely. Scarce personnel is being utilised optimally in terms of keeping them busy and in the meantime, their experience and knowledge ensured the best value for money possible. Time was not a factor until recently. Of course, it always took too long to provide the solutions to the business, but offset against costs, this has always been a small price to pay. Relatively speaking, and yes, pun intended.
But things have changed and the old timelines are no longer acceptable. Timing becomes more and more an issue. Business ideas can no longer wait to find their way into the hands of users. Not only because lean, agile and nimble Start-Ups will chip away the market shares of enterprises, but because enterprises between themselves are leveraging technology to get the competitive edge.
We see that the introduction of The Cloud in the IT departments of enterprises has resulted in extremely short timelines when it comes to delivering solutions to the business by their IT departments. Enterprises with an IT department that can't leverage the characteristics of The Cloud as defined by NIST will perish. You can't move fast enough? You're shark food. It's a dog-eat-dog-world nowadays.

The CIO v.s. the CDO

We see that CIO's are being complemented by CDO's, Chief Digital Officers, in those enterprises where the CIO has not been able to transform the IT department from a traditional silo'd business enabler into a heterogeneous multi-disciplinary flat business partner. CDO's are introduced to drive the digital transformation, a transformation that has been going on since the advent of computers in enterprises. But where it focused on efficiency and controlling cost in the past, now the transformation is focusing on effectiveness and creating value. Often the CIO hasn't been informed about this new direction as often the CIO is not in the boardroom. Understand that in many of the organisations I've been, the CIO reports to the Chief Financial Officer, instead of the CEO, COO or the Chief Marketing Officer. IT is associated with cost in these enterprises and not with revenue.

Product/Platform Paradigm

But in the Cloud Native Enterprise, it isn't the IT department that delivers IT solutions, not even when they can do this with the speed of The Cloud. In these enterprises, the business services it self.
When IT solutions are needed, the business will obtain them by themselves. Here the IT department is no longer delivering the solutions, but the platform onto which the solutions will run and integrate with the core IT systems. Systems like Identity and Access Management, Monitoring and Metering, Resilience and Disaster Recovery. Integration of solutions in the platform is what IT is about. Products and business solutions is what the business is about.
The IT departments in these enterprises are basically nothing more than in-house system integrators. But extremely sophisticated at that since integrations are subjected to profound automation.

It is with Cloud Native Enterprises where we see the true value of the Product/Platform paradigm. IT delivers the platform, the platform is its business product. Business delivers business products. This is where the concept shines as those that understand how to valuate the product from a business perspective are accountable for the product that creates the value to the business.

Concluding

And so the Cloud Native Enterprise is the enterprise where IT is part of the business when it comes to delivering business products. Allowing business solution to be created using IT on-demand, through self-service. This also means that the traditional IT department has become a business department as well, run as a revenue catalyst and not as a cost centre.

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.

Cloud Native Enterprises - Measured service

Which don't have a lot to do with Cloud Native Apps but everything with truely embracing the paradigm shifts the Cloud has brought IT within the realm of businesses.

Read the Introduction first.

After reading the introduction to these posts you know what a cloud infrastructure is and what cloud native applications are, what about cloud native enterprises. Well these are enterprises that adhere to these same 5 characteristics. These enterprises, or organisations in general, cannot be modelled according to traditional enterprise models because of their specific market, competition, growth-stage, etc. These enterprises need to be, for all accounts, be cloud native in order to grow, succeed and be sustainable. Interestingly, but not surprisingly they require The Cloud and Cloud Native Applications.
In coming posts I will address every essential characteristic of The Cloud as defined by NIST from a perspective of the Enterprise. Unlike most cases, I will post these within the next 7 days and I certainly do hope before coming weekend.

• On-demand self-service. When online services and core systems really seamlessly integrate.
• Broad network access. When customers, partners and users are distinct groups treated equal.
• Resource pooling. When synergy across value chains makes the difference.
• Rapid elasticity. When business is extremely unpredictable.

Measured service, when business resources are limited.

This is the post where I'll address the aspect of the Measured service. It is an interesting aspect of the cloud native enterprise because it addresses the financial governance model of the enterprise.
Let me first start with what I witness in most organisations regarding the financial governance model. Great and small, old and new. And even in start-ups. The model is in about all cases one in which there is an annual budget allocated for pretty much everything that costs money. Often times, the budget is based on past experiences. It's a copy of last years budget corrected, or extrapolated, based on last year's developments, revenue, target met or not, etc. What I often times see, and I'm actually pretty sure I have seen this in all but one or two cases, is that once a year there is a prediction as to what the business will look like in the coming year. This is not the strategic plan, but next year's plan. There's a project portfolio, or more recently a product portfolio, that covers the coming year. Predictions are made about next year's resource needs etc.
The most common thing here is that the more resources an organisation has at its disposal, the more anal the enterprise is about these plans.

Being ambitious as a business

What I hardly ever see is a prediction of what the enterprise's ambition is with respect to its market position. Its business ambition. Do not mistake this for a strategic ambition, or a mission statement. What I am talking about is an 'objectives portfolio', an overview of the enterprise's objectives. Each of it's value chains, lines of business, P&L areas, however the enterprise's business is divided should have objectives, and ideally a roadmap littered with objectives. This is the objective-portfolio.

Why this is so important is that an enterprise should be working to meet these objectives in any way it can. And the reason why this is so important, is that these objectives are in fact the key drivers for business sustainability. From a strategy perspective, the business objectives should be completely in line to support the strategy. By working towards these objectives, the strategy is implemented, which in turn will increase sustainability.
An important key take-away is that objectives can be met in any number of ways. There is hardly ever only one way to do so. But in general, out of all the different ways to achieve an objective, there are only one or two that are the best. The best within the context of the enterprise at a specific moment. Which means that what is the best way now, might not be the best way in the next quarter. There could be a missed opportunity, new regulation, or a shortage of resources. So re-evaluating the the proper course of action continuously, should be a given.

For enterprises resources in terms of money are often not considered a bottleneck, instead I see often that the availability of the right people to do the job to be a problem and in even more cases the precious resource we call time is a problem of its own magnitude.
For smaller companies I see that often money is the issue and people and time not so much. Reason being that smaller companies tend to focus more on a limited amount of business solutions. Where enterprises are straying all over the place, small companies are equipped with laser sharp focus.

"Now where's the Measured service coming into play?", you ask.

Measuring achievements not performance

Working with a roadmap based on objectives, with a portfolio of objectives, allows for embracing the concept of validated learning, and metered funding.
Like I stated earlier, objectives are met by choosing one of many implementations, where the choice is based on the context of the moment the choice is made. For example the timing to introduce a new consumer product just ahead of the holidays. Or the introduction of a key competitor's product that will pave to way to broad market acceptance of something controversial. Or the abundance of developers that can code in specific programming language. By consciously choosing the seemingly best implementation to meet the objective, you know what to look for in order to re-evaluate that decision. Staying on track with the calendar to meet the holiday boom, monitoring market acceptance of that product, keeping an eye on Craigslist for job postings for those coders, etc.
Obviously this requires monitoring of the results of your efforts, but that is exactly what it means to apply the concept of 'validated learning'. You determine based on what your efforts are contributing to the bottom-line (whatever that is to you) or not or is even counter productive, this is your hypothesis. You undertake whatever action you've got up your sleeve and once you're done, you check your hypothesis and determine what your next move should do. It's actually pretty close to just being agile.

Turning variable into fixed

Now the trick is, and this is where it becomes extremely complicated for enterprises, to allocated resources in such a way that you can continuously work on meeting the objectives, but change the way you do so, throughout the year. From a financial planning perspective, this is rather different from most enterprises I've seen over the years. Like I stated earlier, budgets are allocated annually, based on plans. The the bigger the budget request, the more assurances need to be given to get the budgets allocated. Business Cases are written, plans are drafted, dreams are... well often the most realistic and accurate of these three.
The way I often see it addressed is by introducing pre-funded teams. Which basically means that one of the larger portions in the budget is fixed, namely human resources. In fact, this only addresses the problem when an enterprises HR strategy is relying heavily on out-sourcing, contractors or a combination of these two. When most of the work is done by own staff, HR costs are already fixed, and working with pre-funded teams is merely an HR-planning issue. I would prefer this situation, but it is often just not feasible. With pre-funded teams, a large part of the budget is fixed, which is an accountant's dream, or so I've been told on various occasions. How to fix all other variable costs? That's a challenge, but this is where a cloud environment helps, as it will not fix IT costs, but it will allow these to be limited to the bare minimum as needed, so costs are not fixed, but risk is contained and limited. Another dream coming true.
Your measured service at play here is now that for one a large chunk in the budget is no longer variable, so planning is straight forward, no measuring is really needed as the teams are based on objectives to be met and not work to be done. I understand this is the first time I phrase it this way but it is crucial to understand the different. I leave you to think about it for a second.

Concluding

Measuring is needed for the remaining chunks in the budget. Although still variable, this chunk, the IT resources costs are contained and limited and investments are only needed when the IT is required. And more importantly, revenue is generated shortly after investments are done, or else further investments are stopped. So we measure the revenue, off-setting it to the limited costs.

I hope you understand the paradigm shift in the financial governance from a mainly cost driven concept where revenue is mainly a matter of wishful thinking, educated guessing at best, to mainly realised revenue based.

Re-iterating. Measured services relate to the fact that the in the cloud native enterprise, the enterprise is governed such that costs are considered investments. But only concerning those costs that can't be fixed. In other words, variable costs are considered investments. Investments are related to business objectives to be met and not work to be done. This eliminates in a large part the risk that the focus is on work already done instead of objectives still to be met when it comes to new investments.




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.

Cloud Native Enterprises - Introduction

Which don't have a lot to do with Cloud Native Apps but everything with truely embracing the paradigm shifts the Cloud has brought IT within the realm of businesses.

A couple of weeks ago I was asked to do a presentation to a number of mainly (project) managers on the topic of "The Cloud". I think one of the reasons I was asked had to do with the fact that I usually tend to be (a bit) iconoclastic and another reason might be that I have been a huge proponent of The Cloud. Look at previous posts of Arc-E-Tect and you should be able to find a number of posts on the topic. In any case, I obliged.

While preparing the slides, digging into my archive of presentations as I remembered a presentation I did on the topic a couple of years ago to a group of mainly lawyers and auditors I decided that it was the perfect time to not talk about The Cloud as an IT phenomenon but as a business phenomenon. As you might have gathered when reading my posts on this blog, I do tend to see IT from a business perspective. Pure simple logic dictates that we apply IT in organisations to strengthen our businesses. The decision was made, I was going to talk about Cloud Native Enterprises.

The Cloud According to NIST

What are Cloud Native Enterprises? First of all you need to know what The Cloud is, and I always use the NIST definition of Cloud. NIST made it easy to define The Cloud by naming 5 essential characteristics of cloud:

• On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.
• Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations). 
• Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.
• Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.
• Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

(source: The NIST Definition of Cloud Computing)

There's not really an order in these characteristics, but they are essential. You have to keep in mind that these are related to IT systems, typically infrastructure hosting services.
I'm not going to re-iterate these characteristics and explain what The Cloud is, instead I'll go over these essential characteristics to explain what a Cloud Native Enterprise is.

Cloud Native Applications

But before I do this, let me explain what a cloud native application is, because it is important to understand this. First of all; Every cloud native application can run in a traditional data center. Second of all; From a NIST characteristics perspective there is no difference between public and private and hybrid clouds. As long as all 5 essential characteristics are met, we can talk about a cloud environment.

Back to the cloud native application. This is an application that thrives on the cloud. It is one that uses the 5 characteristics to the fullest and doesn't compromise. Let me go over them one by one.

• On-demand self-service. A cloud native application is accessible by a user, which could be another application, but often it is a person. But it is not only accessible by a user, but everything pertaining that user can be done by the user, whenever the user pleases. So the user can sign-up herself, configure her environments herself and do whatever she needs to do, all by herself. Irrespective of the role of the user. So an administrator of the application can do whatever needs to be done, as can a business user. This is hugely different from traditional applications, where you would need to request an account at some service-desk in order to gain access.
• Broad network access. Cloud native applications are network accessible and not only that, they're accessible through standard mechanisms and through common devices. Typically we see that these applications are accessible via the internet, or at least through internet protocols. Often we use http or https to access the applications. Originally through a browser, but with the advent of mobile devices we see that the generic web-browser is replaced by a specialised browser, the client application, that accesses the application's logic via web- and internet-protocols and presents a user experience fully embracing the client device's capabilities.
• Resource pooling. This for applications means that the applications are multi-user applications and the users are not aware nor impacted by each other, unless of course, business logic demands interaction.
• Rapid elasticity. Probably the most unique selling point of the cloud is elasticity. The amount of resources needed to perform a specific task consistently independent of the load on the systems is expanding or retracting as needed. Elastic. No wonder Amazon calls their virtual server environment Elastic Cloud Compute (EC2). For cloud native applications the same goes. The application scales up and down as needed by the load on it. Typically this is done using the underlying infrastructure's elasticity, but mind that the cloud 'nativeness' of the application is that we're talking about functional elasticity. The responsiveness of the application is consistent across many workloads. This can mean that the application's functionality scales down when load increases (e.g. loading only the first 3 review comments for an item in a web-shop instead of 10) and scales up when the load decreases.
• Measured service. Here we run into the situation where the usage of the application is metered. At any time it is known what the application's utilisation is. Which user is using what functionality at what time with which guarantees. The idea here is, obviously, that the user will be billed based on her usage (of resources) of the application in contrast to some flat fee or a compute-power based fee. An example is that a free-tier account can access a certain function only once every two seconds, where a pro-tier account can access the function 5 times a second. The key here is metering and billing.

Every time I use the word 'user' above, I want to reiterate, it can be a person, but also another system. Especially in the current API economy, the user mentioned will very likely be another application.

Applications that are cloud native adhere to these 5 characteristics, and they do this from a business functional perspective. There are all kinds of technical implications like a transition from ACID transactions we typically see in traditional applications, towards BASE transactions we see in cloud native applications. Same goes for in depth security in the cloud and more of a focus on perimeter security in traditional data center hosted applications.

Cloud Native Enterprises

Now that you know what a cloud infrastructure is and what cloud native applications are, what about cloud native enterprises. Well these are enterprises that adhere to these same 5 characteristics. These enterprises, or organisations in general, cannot be modelled according to traditional enterprise models because of their specific market, competition, growth-stage, etc. These enterprises need to be, for all accounts, be cloud native in order to grow, succeed and be sustainable. Interestingly, but not surprisingly they require The Cloud and Cloud Native Applications.

In coming posts I will address every essential characteristic of The Cloud as defined by NIST from a perspective of the Enterprise. Unlike most cases, I will post these within the next 7 days and I certainly do hope before coming weekend.

• On-demand self-service. When online services and core systems really seamlessly integrate.
• Broad network access. When customers, partners and users are distinct groups treated equal.
• Resource pooling. When synergy across value chains makes the difference.
• Rapid elasticity. When business is extremely unpredictable.
• Measured service. When business resources are limited.

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.

Kanban board for my 12 year old son

Last week my oldest son and I wiped the family whiteboard in our entrance hall and turned it into a Kanban board. The reason for this was that he, my son, was facing a period with a lot of tests at school. He's 12 and in his second year of Gymnasium. And he realised that in the coming weeks there would be a lot of tests as we're approach the end of the 3rd quarter of the school year. There was a slight sense of panic at the time, because he wasn't convinced he could prepare for all tests sufficiently.

So in order to make it more visible to him what needed to be done, and what was already done, we turned the family whiteboard into his Kanban board. With 4 columns (planned, to-do, doing and done) we choose a simple but pragmatic approach. Every gradable homework would be written down on a post-it and we choose the pink post-its for this, it's the 'Grade Ticket'. And the date of the test or on which a paper or report had to be handed in would written on the card as well as some description. The card would be placed in the column Planned. This way we make it visual what's coming up in the next few weeks.

Grade Tickets that need to be worked on are accompanied by Task Tickets, which are either yellow or green, depending on the color of the post-it at hand. This is for every Grade Ticket that my son feels as needed to be worked on. The selection criteria being that he needs to be able to finish all the work to be done before the due date without being overwhelmed with all the work to be done so he still has time to play Rainbow Six Siege and Fortnite Battle Royal with his buddies.

Like I said, we're very pragmatic about this, and I am sure that quite a few of you won't agree that this is a real Kanban Board, but my son and I don't care as long as it works. By being pragmatic, we have every Task Ticket dated as well, meaning that we write the date on which the task should be completed on it. After a week working with the board, this also means that the date means the date on which the task is actually done. The tasks are very simple ones, obviously, because they can be started and completed on the same day. These could be tasks like "Learn the translation of 25 words in Latin" or "Learn to apply the first law of physics in a vacuum". As long as it can be started and finished in a day.

What my son gets from this, is a clear overview of what tests and papers are due at what date. What tasks he needs to work on to study for the test or to hand in a paper. And when to do it. What tasks (still) need to be done today, and what has been done for a particular test. Every time he walks down the stairs because that's where the whiteboard is fitted to the wall, at the end of the stairs. There is no need to open his laptop to check on his assignments in some system provided by school, nor does he need to open his agenda. There is absolutely no need to do anything for him to know what he needs to do. "In yer face visualisation."

What my wife and I get from this, is that we now know exactly what tests he has, and what our son has already done in order to prepare for the test. We get better insights into how he's doing in relation to what he should be doing. Without having to ask all the time, which removes a lot of tension and irritation from our home.

Of course we have implemented some metrics as well. Reason being that this is an experiment so we need to know whether or not this is beneficiary for primarily our son. The metrics we're gathering are first and for all about whether or not our son feels that he is more in control of his tests and papers and the work to be done. We want to know whether the panic-metric is going down in the coming weeks. Another metric we're keeping is how much time he can play Rainbow Six Siege and Fortnite Battle Royal with his buddies. He has a 'screen allowance' of 1 hour on a schoolday and 2 hours on a non-school day. Every day he's able to spend his full allowance is counted and we're interested in whether or not he reaches the maximum possible time playing those games. And then we're keeping track of his grades and are expecting to see the same grades as before or better. Where we do factor in the subjects of the tests and the amount of tests in a single week and so on. So we compare the grades with the final few weeks of the previous periods.

So far we have some results already. First of all, our son is feeling definitely more in control and has greater confidence that he's preparing sufficiently for the tests. One of the reasons is, his words; "because I can now see what I need to do when I come down the stairs so I have less worries that I forget about a test". Another great aspect is that he too is less frustrated because we are not asking him all the time how he's doing with his home work. Already we trust him more and he is receiving more freedom, he's more autonomous, to determine when to do what. So far he has also played through all of his allowance and finished a book. So it seems he does have more time to spare. No grades yet, but we're confident.

So far, our Student's Kanban Board seems to address our son's problems, I guess we do have problem/solution fit. And our son is now using the board without any help and without any significant effort. So I guess we also have product/market fit. (our son is our market in this case).

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


Disclaimer: This article was cross-posted on the Words from the Netherlands blog and LinkedIn. 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.

Metrics Matter - An Introduction to a series on Measurements in an Agile world.

This will be a series of posts on metrics, KPI's and measurements as they relate to agile concepts, teams, organisations, etc.
I started on these posts some time ago after numerous discussions with several of my clients on the topic. My initial post started to become really long and after I discussed some of the concepts with peers at the Lean Startup Summit Amsterdam 2018 I decided to have several posts on the topic of metrics, starting with measuring agile teams.

Before I dive into the topic of metrics and agile teams I want to highlight a couple of observations related to this.

First of all is the notion of agile transformations. In the last decade there have been a number of large organisations that made the transition from a traditional hierarchic organisations embracing a risk averse policy when it came to business development towards a more innovative and iterative stance where experimentation and feedback cycles were employed to limit risk. Companies like ING Bank, G.E., Intuit and several more are well known and well documented. One of the most heard reasons for doing this transformation relates to an ever faster changing environment in which these organisations operate. In many occasion I have heard that the democratization of IT infrastructure like the cloud has been a key player in setting the urgency to transform for these organisations. Where as in the past competitors faced the same problems as these organisations sharing the same risks, new players in an ever more crowded market (any market) have adopted a new model of operation in which these challenges and risks are no longer a factor.

New and foremost nimble organisations commonly referred to as startups have surfaced and without the lack of legacy both in investments as well as organisation and culture are more capable of addressing the market's needs than their large(r) counterparts. Often the Chinese proverb 'death by a thousand cuts' is used when referring to large corporations loosing market share to small companies.
The realisation that the new kids on the block are formidable and sometimes fierce competitors, plays a key role in these 'agile transformations'. This all happens in a market that is more and more addressed by regulators. Not so much to control and protect national investments, but to open up internationally allowing foreign players into domestic markets and to support competition.
What I see happening all around me with clients of every size is the realisation that without innovation, business fear for their sustainability. An important but often missing realisation is that the lack of innovation in an organisation is the result of a rigorous focus on costs instead of value. The larger the company, the more focus on efficiency in the past. I have written about this before, read the post [Perish or Survive, or being Efficient vs being Effective] for example.

What I see happening a lot is that organisations are trying to redefine their focus but maintaining their means of measurement, i.e. the metrics used to validate the organisation's progress are left unchanged while transforming the organisation from one that's efficient into one that's effective. Or in different terminology: The Agile Transformation.

Caveat emptor: Unless your objective is to become more effective and are willing to move your drive for efficiency to the background, an agile transformation is a lost cause and a waste of resources.

Assuming you're doing an agile transformation for all the right reasons, you will get to a point where you'll realise that you will need to change your KPI's and more importantly, you will need a set of metrics that allows you to validate the effectiveness of your transformation.
Just a little terminology definition is warranted here. I know the theory behind metrics, KPI's, measurements, lagging and leading, etc. But I am maintaining a rather simplified view on things:

• KPI's, Key Performance Indicators, are typically found in reports. 'Past perfect tense' is their use and they indicate whether or not you've reached your goal.
• Metrics are typically found on dashboards. 'Future time' is their use and they indicate whether or not you're on the right track or are in need of a change.

Forget about all the other theory around KPI's and metrics and all. To understand these posts, this is all you need to know. In all fairness, I think KPI's are something of the past when we are talking about agile transformations. Well at least when it were up to me. And this is not because KPI is an acronym but because I think the better measurement would be the KVI, the Key Value Indicator. The difference is that instead of performance we measure value. We're not measuring how efficient we are, but how effective we are instead. Cost vs. Value.

So I'll also talk about KVI's instead of KPI's in this and the following posts. It is also more in line with autonomy, self-steering teams and the more recently hipster term OKR's (Objective and Key Result) which will be addressed in one of the posts in this series as well. And in particular why you should be very careful with applying them in your organisation.

In this series of posts I will cover the following high-level topics:

• Measuring Agile Team performance. In this post I will also address the challenge of maintaining the integrity of the Team-accountability while looking at individuals as well as teams when measuring performance.
• Agile Maturity. This post will cover the aspects of maturity scans, their value and why you shouldn't care.
• Agility Metrics. A post that will address how to implement metrics that measure your agility. Especially valuable when in the midst of an agile transformation.
• Business value and Metric Harmonisation. An important aspect of keeping stock of your KPI's (and KVI's) is making sure that between teams they are not conflicting.
• Visualisation and Dashboarding. I'll explain why there is no single one dashboard. Why visualisation is extremely important when using metrics and how dashboard, metrics and proper visualisation ensure a lack of surprises in your KPI's. Which will highlight the necessity of using KVI's instead.

So that's at least 5 more posts on the topic for you. Depending on the time I have to spare in the coming period, you'll be able to find the posts sooner or later. Please keep in mind that I will most likely post some articles on other topics as well. I'm dying to shed some light on the challenge of BizDevOps in large organisations. The real challenge I mean.

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.