Go Bimodal in Your Enterprise: Stop Shaving the Yak!

So, you are in charge of the bank’s customer website, and you want to add a congratulatory message when a customer has finally finished paying off a loan. A nice touch, isn’t it?

The problem is that the website is a JavaScript-based, single-page web application consuming REST APIs, while the loan application is an outdated system running COBOL. But that’s what enterprise service buses (ESBs) are for. You quickly set up a client-server connector to the loans system and start mapping the COBOL parameters into a usable web service that can be fed to the ESB and transformed into a RESTful API. But to get a web service to the ESB, you need to first create an XML schema for it. Then you realize that for a data item to appear in the schema, it has to first be defined in the central data dictionary, which is managed by a team of data architects—who will be more than happy to help you, once you clear everything with the data security team. The security team will be absolutely thrilled to give you the OK once you change the connection to the loans system into a secured VPN, which is only possible with a static IP address—which renders your disaster recovery procedures useless.

So, here you are, rewriting server initialization scripts, all just to tell customers, “Hey, great job clearing that loan.” You are shaving the yak.

Coined by Carlin Vieri in his time at the MIT AI Lab based on an episode of the cartoon The Ren and Stimpy Show, and popularized by marketing guru Seth Godin in the mid-2000s, “yak shaving” means the last step of a series of steps that occur when you find something you need to do. You want to wax the car, but the hose is broken. You’re ready to go to the hardware store for a new hose, but you don’t have your EZPass. You ask your neighbor for his, but he won’t lend it to you until you return the yak-hair pillow you borrowed, which you can’t do because the stuffing fell out. Now, needing to refill the pillow, you find yourself at the zoo at 8 a.m., shaving the yak.

We have all been there. Large enterprises have complex IT architectures with a lot of moving parts and a lot of things to consider. Usually we consider this reality as the only one possible: “Yes, it will take us six to eight months to get you a car insurance quote as an API. Yes, we think it’s completely acceptable, given the complexity involved.”

But it isn’t; not anymore. Today’s business needs can’t allow for yesterday’s time frames. Eight months is enough time for a young startup to completely disrupt a market, transforming your IT department from an asset into a liability.

On the other hand, you do need the security, robustness, and reliability that come with these products and procedures. Central service buses, data dictionaries, security requirements, customized auditing and logging, tailored deployment procedures, etc., all happen for a reason. For the most part, you can’t just throw them away without expecting chaos. What can you do?

Going Bimodal

Enter the bimodal approach. Bimodal refers to two modes of operation that an enterprise can support at the same time: the first one, the stable mode, is the one you already know; it’s the robust, safe, and slow one. The second one, the agile mode, is a fast path that exists alongside the first mode and allows you to get results done quickly and without much fuss while not compromising the integrity of your IT.

Imagine you had a way to create a standard RESTful API for your loans application, with standard security features, deployment procedures, and auditing capabilities that, while not necessarily compatible with your current practices, are based on best practices and standards that can be integrated easily at a later time. Get results now, and make it fit perfectly later.

Using the bimodal approach, organizations can move quickly to grab opportunities and make the most of their IT capabilities without being hindered by their complexities. This, of course, does not mean throwing away all the rules. For some processes, you cannot take a shortcut; some aspects must always be considered. But the question to ask is: Do I have to do this in a tailored proprietary way, or are the common best practices good enough? Yes, it is better to have all logging records comply to a specific proprietary format, which makes it somewhat easier to process at the end of the year; but is it really more important than going to the market sooner with a solution? Isn’t the NCSA Common log format good enough?

The Five Attributes of an Agile-Mode Solution

How do you recognize an agile-mode solution? How do you evaluate if a specific product or tool will support this mode of operation?

The first thing to know is that the way you use it is more important than the way it was meant to be used. If you find it easier, cheaper, and faster to use a hammer to crack a nut, then go for it. But you need to consider some common attributes for agile tools that will support your bimodal fast path.

Standard-based: Using well-established standards is important for all things IT, but for agile-mode tools, it is even more so. Consider the fact that everything you do with these tools or products will have to integrate eventually into your stable-mode architecture. You never want proprietary or hard-to-integrate modules giving you a hard time down the road.

Convention over configuration: The idea of valuing best practices and conventions above configurability and freedom of choice may prove objectionable at first for technically inclined individuals. They know what they are doing and don’t need a tool to enforce “the right way” on them. The fact of the matter is that even if you have a better way of doing things, in this mode, best practices are still better. That is because this mode is about speed of delivery and the ability to perfect it later. Best practices and conventions should be considered as much of a standard as XML or JSON. You may have a better way of formatting data, but you are still better off using something that every tool and product out there will support.

Automation: It goes without saying that automation saves work and time. What is also important to remember is that it enforces standards and best practices and prevents human error. When considering an agile-mode tool or product, the more automation it provides, the better.

Comprehensive solutions: An agile-mode tool should provide a solution, not a steppingstone to a solution. While specialization may have many benefits, an appliance for filtering out data according to user roles may be the most efficient in doing just that; in the context of agile mode, it is not necessarily a virtue. Agile-mode tools should provide a streamlined, comprehensive way of getting you from a problem to a complete solution as quickly as possible. If you have to string together multiple tools and products, each one being the best at what it does, it just adds to the complexity of the solution and delays implementation.

Single user: An agile-mode tool needs to be not only comprehensive in what it does, but also able to be operated by a single user or team. Going to multiple people and teams to get permissions, definitions, configurations, and setups is probably the most time-consuming aspect of any IT effort. By limiting the number of people involved, you can speed up delivery dramatically. Of course, this does not mean you can do whatever you want without the data security team having anything to say about it. Remember, you are using best practices that have been prechecked and preapproved so that you don’t need to go through the entire security threat evaluation process every time you expose something out to the web. This is perhaps the trickiest attribute to achieve. Maybe going for single-user may prove overly optimistic, but you should definitely try to minimize the number of people involved in implementing and deploying an agile-mode solution.

The new problems facing enterprises today cannot be fixed using old tools. While traditional IT will stay with us for a long time, a different approach must be implemented for those cases where speed is of the utmost importance and the opportunity of threat has to be dealt with as soon as possible. Big architectural IT changes—much like yak shavings—aren’t necessarily the wrong thing to do. After all, someone will have to do it at some point. The only question is: Do I really need to shave that yak today in order to get my car waxed?