The Bimodal misconception, why Gartner has to realize the ignorance of its customers

Okay, first of all, I'm talking about Gartner's Bimodal IT thing here which is defined by them, that is Gartner as follows: "Bimodal is the practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration.", which is taken from here. And it makes no sense, because Gartner omitted to mention that this is an application architecture thing.

The problem I have with Gartner's definition of Bimodal IT is that it implies rather explicitly that predictability and exploration don't go together, which is of course totally correct. You explore because you can't predict. But the reason why Bimodal IT was introduced is because we face a stand-off between waterfall and agile, between Silo'd IT and DevOps, between client/server and service oriented systems, between legacy and the new world.

Reading the rest of Gartner's definition (Mode 1 is optimized for areas that are more predictable and well-understood. It focuses on exploiting what is known, while renovating the legacy environment into a state that is fit for a digital world. Mode 2 is exploratory, experimenting to solve new problems and  optimized for areas of uncertainty. These initiatives often begin with a hypothesis that is tested and adapted during a process involving short iterations, potentially adopting a minimum viable product (MVP)  approach. Both modes are essential to create substantial value and drive significant organizational change, and neither is static. Marrying a more predictable evolution of products and technologies (Mode 1) with the new and innovative (Mode 2) is the essence of an enterprise bimodal capability.) you understand the flaw in their reasoning. The flaw is in that the definition assumes that an organization can be divided in two ways of addressing its business, or rather that it can adopt a way of working in that it addresses its business simultaneously in a 'we know what the customer wants' and a 'we want to know what a customer wants' way of working. Which is bogus, of course. Totally bogus.

At one of my current clients, Bimodal IT is a hot topic. Here it is used such that the back-end systems are considered Mode 1 systems and the front-end systems are considered Mode 2 systems. Furthermore, the epic mistake is made to consider everything running in the cloud to be a front-end system and everything in the on-premise environment, which is a traditional data-centre, to be a back-end system. Makes no sense to me, and I can guarantee that within the next 6 months there will be back-end systems running in the cloud.

To understand Bimodal IT, we need to understand why the term was coined. Basically, you need to re-read the definition and understand what is being said. You need to put it in the context of time, and address it from an architectural perspective. Because that is what Bimodal IT is, well that is its raison d'etre.

So, let's start with 'one focused on predictability' and forget about this. It's an ambiguous term. Ambiguous because for one we want our software delivery cycle to be predictable, we want the quality of our solutions to be predictable and we want the costs of our solutions to be predictable. At all times, no difference between front-end and back-end, no difference between cloud and data centre and no difference between old and new. At the same time, we can't predict what the best feature set of our solution is. We can't ever predict it, no difference between fron
t-end and back-end, no difference between cloud and data centre and no difference between old and new.
So predictability only applies to our solution delivery process and not to our solution.
And then there's 'the other on exploration' which we should forget as well. It's an ambiguous term as well. It's ambiguous because we need to always explore to find the right feature set for our solution. This is because we can't predict the right set. It has nothing to do with where we're hosting, whether it's front-end or back-end or anything else.
So Bimodal IT by Gartner's definition makes no sense, because from the outset it's wrong.

But here's the catch, at the time Gartner coined the term, it made perfect sense. It's just that Gartner forgot to mention that Bimodal IT actually hinges on application architecture.

Back to this customer. Bimodal IT is used as an excuse not to comply with the ancient and really seriously out dated processes in IT that are (to be) followed within this organization and I assume unwillingness to try to modernise the processes. By just simply referring to Gartner and their definition of Bimodal IT and stating that this is the exact situation at their organisation, some of my clients architects and project managers are implying that the processes only apply to what's running in the back-end and what they're working on, which is the front-end.(*)

Let's see why thinking in terms of Bimodal IT is making sense. It makes sense because at the time Gartner coined the term, we developed our systems predominantly being Waterfally and the hipsters were being Agile. There was nothing exploratory about it, and read the Agile manifest and it says nothing about exploration, but the more about predictability.
Mode 1 and 2 are all about delivery cycles. Mode 1 is long, Mode 2 is short. One could say Mode 1 is about being ignorant and Mode 2 about being smart.

So, ignorant vs smart, what's that about?

Well, in Mode 1, we tend to think that it makes sense to first define the complete solution, design it and build it before we deliver it to our users. And because for some reason, release into production always results into (often major) headaches, we also tend to think it makes sense to not release that often, so we limit the occurrences of headaches. Hey, if you only bang your head against a wall twice a year, you only run the risk to crack your skull twice a year. So makes perfect sense, doesn't it?
Then there's Mode 2, where we think that is makes sense to just grab the most important, or valuable features and develop these and take them to our users, and then do it again with the next most valuable solutions and put them out to our users. And we tend to think that because we only release a tiny thingy, it's very unlikely that it'll go wrong and will only cause (if at all) a dull feeling in the back of our head. Hey, if you nudge your head against a wall every few days, at the most you know that the wall is still there, but that's about all to be felt.

So Bimodal IT is where one group of people thinks that doing something really hard is less risky when you make it even more complex but do it fewer times and the other group of people thinks quite the opposite, that doing something really hard is less risky when you simplify it and do it more often. Kind of practice makes perfect.

And yes, years ago when Gartner came up with Bimodal IT, we really had this Mode 1 and Mode 2 division as described above. But in this day and age, the Mode 1 people are a rare breed. Mind that we're discussing this in an era where major banks (ING) are firing pretty much everybody that is Mode 1, where major airlines (KLM) are spending millions of €'s to transform in to a full Mode 2 organisation and where it's hip to be Mode 2 at IT departments of local and national governments.

But Bimodal IT is there to stay for a while. Not because of predictability, nor because of exploration. Not even because of Waterfallians (Mode 1 people). Nope, it's because of Monoliths. Those ancient systems that were delivered in a day and age when we thought Client/Server was awesome and everything should be consolidated into one system so we could guarantee data consistency and we could really vouch for abiding to the DRY principle (Don't Repeat Yourself).

These systems can't be changed, they are architected to be unchangeable. We don't want them to be that way, but they are. It's because our application architectures of a couple of years ago resulted in unchangeable systems, we can only change them by changing the complete system. The monoliths are preventing us from becoming post-Bimodal IT organisations.

Back to the misconception. Bimodal IT is something that has to do with the monoliths in our IT landscape and nothing with how we perceive our IT or the systems in our IT landscape. The misconception is that we need to adopt a Bimodal IT approach to how we do IT because we don't have to. We have to get rid of the monoliths and we need to start by isolating them behind a layer of changeable software. Hide them like a skeleton in a closet of services.

By adopting Bimodal IT today, or continue with Bimodal IT today, means you either have a totally wrong understanding about how to manage your IT department, or you are still in the previous millennium when it comes to IT architecture, or you're just using Gartner's reputation as an excuse for not having to modernise your IT processes.

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

Iwan


Although this post is my personal opinion, there're quite a few articles to be found on the internet about this topic that I've read. So here're some interesting reads:

- Gartner Glossary: Bimodal IT
- Gartner's bimodal IT mistake: DevOps can deliver velocity and quality
- Bimodal IT: Gartner's Recipe For Disaster
- Beware the Dangers of Bimodal IT
- Gartner’s Evolution of Bimodal IT
- The Flaw at the Heart of Bimodal IT




*: Interestingly enough, they forget to mention that the back-end is running on-premise and they're in the cloud and yes, the front-ends hosted on-premise are just as much under the same regime as the back-ends.

Architecture Principle - Service Interface Compatibility Principle

Architecture principles are ground rules by which we develop our software. This ranges from ways of working to styles of coding, from software decomposition to business compliance, from infrastructure choices to security implementations. As you can see, it covers pretty much everything related to the development of business value, online, offline and internal.

Description

The typical SOA application landscape is defined by services. Through service orchestration the behavior of (online) services is implemented, business value is created. A service consists of two parts;

1. The implementation of the service, 
2. The interface of the service. 

Both components have their own respective life-cycle. Resulting in a situation where through time the implementation of a service is evolving typically to support evolving non-functional requirements. For example to evolve from a relational database to a NoSQL database. Or from home-grown development to the use of an online service. Analogous, the service interface can evolve over time as well, typically because the resource it represents evolves over time. For example the amount of data captured about a customer can increase over time from just a name and number to also include an email address, date of birth and marital status.

Service implementations typically change because of (more) technically driven reasons, will service interfaces typically change because of (more) business driven reasons.
Where as the service implementation is more of a service internal discussion, i.e. how the service is implemented is irrelevant as long as the defined behavior is provided, the service interface is a service external discussion, i.e. how the service can be consumed is relevant to whomever uses the service. Thus, the service interface must be kept as stable as possible, i.e. when the service changes, the interface should stay relevant for existing users and become relevant for new users.
Service interfaces can change for three reasons, that have to be factored in when complying to this principle:

1. The resource represented by the service becomes richer, i.e. fields are added. In this case there is no impact to existing consumers. Provided that the the consumer abides by the principle that 'Unknown makes Ignored', in other words, the consumer will ignore any fields that it wasn't aware off. For example, with a Person resource that contains a Name and a Phone number, the new version also holds and email address.
2. The resource represented by the service syntactically changes, i.e. existing fields in the resource are for example renamed because of an enrichment of the resource data. For example, with a Person resource that contains a Name and a Phone number, the new version renames the Phone number to Business phone and adds a new field Mobile number.
3. The semantics of a resource changes although the data doesn't necessarily changes. For example a Person resource becomes a Law Enforcement Agent as all captured information pertains agents in law enforcement.

Keep in mind that the service interface is a contract, it is not just the technical procedure/function call or the URI to access the service, but also the description of the input and output values. Their constraints, limitations etc. Hence the reference to 'behavior' in the text above. For more on behavior see my post Oh Behave! How JIRA turned into a Veggie Salad.

Rationale

Since a service doesn't know about its consumers, the Producers make no Assumptions about Consumers Principle, it is unknown what the consequences are of changing the interface of the service. And therefore it is impossible to quantify the impact of such a change, hence the viability of that change is extremely hard to define. So the interface can not change, or rather, changes to the interface may not impos an impact on any of the consumers.

Implication

The implication of this principle relates to both the service as well as the consumer of the service. In all cases, the old interface should stay available for those consumers that rely on the old interface.

Producer implication

Service interfaces are to limit the impact of change, meaning that syntactic changes to the resource are to be implemented by extending the resource, i.e. adding fields, instead of changing the existing resource, i.e. changing fields. This caters for changes 1 and 2 as described above. Service interfaces that require a semantic change, i.e. the change defined in 3 (above), in fact result a new resource, and hence the identified of the resource should change.

Consumer implication

Consumers must abide the principle of 'Unknown means ignored', hence any information in a resource that is unknown, should be ignored.

References

Your API versioning is wrong, which is why I decided to do it 3 different wrong ways
VERSIONING REST WEB SERVICES
Versioning RESTful Services

Oh Behave! How JIRA turned into a Veggie Salad

Hi,

Previous I posted about Why Uber is so applicable in the agile delivery of softwarer. It is only part of the story about how agile delivery is doing stuff differently from many other development practices.

Provided you have access to the JIRA and Confluence sites of one of the companies I worked for recently, which is the FinTech startup dopay, and you're following the various tickets on JIRA and read the relevant wiki site every now and then, you will come across terminology like Cucumber and Gherkin. Probably you've been wondering when you would come across Tomato and Lettuce as well. Chances are you will, because JIRA is turning into a Veggie Salad. This is, by the way, a trend you'll come across throughout the agile world.

All jokes aside, what's all this vegetarian mumbo-jumbo about.

Cucumber is a tool in use at many agile teams to verify that the developers build the right swing. Swing? Yes, swing, agile development is all about building the right swing .

You'll hear me refer often referring to the swing, and most of the times proclaiming that I want to make sure we create the right swing. The point in building the right swing is making sure that what ever is being build is behaving in the right way, is delivered at the right time and costs just about the right amount. Getting all three right is extremely tricky, and pretty close to impossible. So we go for the system that behaves the right way first and get as close as possible to our two other goals, making it on time for a decent price.

I'm using the term 'behave' deliberately. We don't want a system that has the right functionality but isn't usable, instead we want a system that is usable and as such, it will deliver the right functionality. There's a small difference in wording which is crucial. Here's an example:

Say you need to enter the details of an employee for one of the customers in a HR services system. Now the system would provide the function to enter employee information in a nice slick wizard interface, taking you through the whole process and when you're on page 6 and press the submit button all details are stored in the database, which is when you find out that the format of the mobile number of the employee had to be international. Good thing the faulty data wasn't stored, because it would corrupt the database. And now you can enter all data again, as the helpful system did a reset of the screens so no corrupt data can flood into the database and you're getting a second chance to enter the data correctly.

The functionality is exactly as it should be, employee details can be entered, the system validates all data and ensures that only correct data is entering the database. Awesome. Or not, as in fact this is what we want, yet is not really what we wanted. What we wanted, or what what I would've wanted, is that the system would have behaved in such a way that it would have me entering the data and as I go from field to field it would validate the information entered and inform me straight away that the data was incorrect and let me fix it without resetting the fields already entered correctly. It's the same functionality I'm getting of the system, but the behavior is what mattered. And I hope you saw the way I expressed that functionality in terms of what I want the system to do, and not to provide.

I want behavior.

I want behavior? Yeah, and good behavior, I want this from my kids as well as from the systems I use. Mind that I want my kids to get good grades in school, but not by cheating, but by doing their best.

We describe the behavior of our systems in such a way that we can not only document the behavior we expect from our systems, but we can test that it really behaves that way. The documentation is done using the language Gherkin and the testing is done using the tool Cucumber. And no, these are not the tools for the developers, these are the tools for the entire enterprise. And I can hear the screaming starting;

 Ohhh no, now he's asking me to start programming in some weird programming language,  AAAARGH!!!

Actually, you couldn't be more right. I do want everybody to start programming, and use that weird language Gherkin to do so. But unlike those obscure programming languages that are used by those developer types you see wandering around in office, Gherkin is really simple to be used. In fact, you've already been programming in Gherkin for the larger part of your life. Gherkin is just plain English (or any of about 40 other languages for that matter). Gherkin is really easy to write, read and well, read and write. But first let me show you a little piece of behavior description that is more formal than a typical requirement: 

Given that our sales agent Johnny Dough already registered ACME Inc as a customer, when Alice is accessing her Sales Management Dashboard to access the latest sales reports, then she will need to log into the customer portal first. 

I hope the line above makes sense and it is perfectly clear how we want the system to behave when a user wants to access her data. And guess what, that was all perfect Gherkin. Yup, Gherkin is human readable and not just developer readable. The cool part, this is also 100% the test script that will be executed to test the system.

SAY WHAT!!!!

Yes, you read it right. While you document the features of your system, i.e. the way you want your system to behave, you create at the same time the test scripts to verify that the systems really behaves that way. No more excuse that the wrong swing was build. And oh, there's another little interesting piece that you might have guessed from that little Gherkin script, it has an actual example of real life data in it. It's Johnny Dough that registered the customer, ACME Inc, and it's Alice who will have to log in. So we explain the behavior we want by means of concrete examples, not some vague abstract wording.

For you, my dear reader, this means that you'll be able to read and understand how the system will behave and you can comment on it, you can make adjustments. And more over, when you are the one that requested some feature, you'll be the one that can verify whether or not the behavior is documented correctly, maybe even document it yourself. It has become irrelevant who you are, as you understand what the system is doing and in which cases.

Having said this; when the user stories in JIRA state you as the stakeholder,

I as the <STAKEHOLDER> want <CERTAIN BEHAVIOR> so that I can <GET BUSINESS VALUE>

I as the Cards Operations Manager, want the last updated customer at the top of the list of customers in the dashboard so that I can continue working on that customer when I wasn't yet finished entering all data

In the sample user story above, the Cards Operations Manager will be the right person to determine what the exact behavior is that he needs and verify that the Gherkin scripts do specify that behavior.

I hope you enjoyed reading this post, and that you'll be writing a lot of Gherkin, because we tell our system: Oh Behave! 

: The swing cartoon originally referred to the problems around the waterfall method, and was a case in point for moving to the iterative product development approach. But the problem is still there, the impact is just less significant. The bottom line, as shown in the cartoon, is that everybody has their own perception of what is needed, hence we need to all work together to get the right perception because it is the combination of all the views on the product that creates the most value. We do this by describing the wanted behavior in terms of scenarios that reflect the input of everybody within dopay. Because we're all unique, and together we're AWESOME.