Why Uber is so applicable in the agile delivery of software

After a short week abroad and various discussions with some excellent developers over there, it is clear to me; Uber is not just very convenient when you want to go from A to B in Cairo, but it is also extremely applicable when discussing the way we develop web-services.

Let me explain to you how Uber got into being. In fact, how Uber Black got into being. It all happened in New York City, a buzzing city where it pays not to have a car and have somebody else drive you. Reason being that parking in NYC is rather problematic if not costly. So when you walk around in the Big Apple, you're bound to see those yellow cabs, the iconic taxis in New York City. And while you're at it, you'll see those large limousines, Lincoln Towncars mainly. These are black, and these are very convenient, luxurious means of getting around in New York. The problem with these limo's is that you have to call them, they're not allowed to respond to the cab-hailing crowd on the sidewalks. The crowd is for the yellow cabs, the customers of the limo's are at home. You have to call them. They're somewhere out there and you have to wait for them to arrive. And that's where the problems start since neither driver nor drivee knows where the other person is. So when it takes too long for the limo to arrive, you're bound to become impatient and call another one, or just walk out the door and hail a yellow cab. They're in abundance. So eventually the limo driver shows up at your doorstep with you already gone. A situation that's not cool for the driver and so next time he hits a traffic jam, he'll just ignore you and wait for another ride, even though you're all patience and waiting for the limo to arrive... soon. It's a bad experience for everybody.
Uber solved this by providing both customer and driver with an app that shows exactly where the other person is. So you know where the heck the driver is and the driver knows exactly where he has to pick up his customer. Furthermore, as everywhere in the world, customers in New York don't trust the cab-meters so there's always a dispute about the cost of a ride. Another problem that was solved by Uber as they want you to state where you want to go and by means of the GPS of your phone they know where you are. So you get a quote of the price and that's it. No more disputes about your fare and since you've provided your credit card, no need for change. Oh, and those weird, rude and above all smelly drivers are getting a bad rating, so when a badly rated driver is responding to your request for a car, you just cancel the ride and try again.

So now let me explain the way Uber works, from a consumer perspective, for those that are not (yet) familiar with the disruptive nature of Uber; First of all, you need to have an account with Uber, that holds your name and your payment method, as well as your phone number. So basically Uber wants to be able to know you, wants to know how you'll be paying for the services and how to contact you. Once you've got your account all setup, you can use their service. Even in cities without limo's you can use Uber, it's called UberX and it's an alternative to other taxi services.
When you need a car, you typically start the App on your phone and it recognizes where you are, based on your GPS location and it asks you where you want to go. Then you can see the cost of the fare and when you're okay with this, you request a car. This is where the fun starts, because a driver accepts the ride and you can see who it is. And you can see his rating. You like it, you ride it.
As soon as you get to your destination, all is done. No need to pay, because you're already set up to pay by credit card. And you're asked to rate the driver and maybe put some explanation on why you rate him the way you rated him.

Basically this is exactly how we develop or should web-services. I'm sure I don't have to explain this uncanny analogy. But I will, while I'm at it. Why stop?

When we develop web-services, we know where we are and where we want to go next. Actually, it's so much like traveling by any means other than driving yourself. We always need to know where we want to go. It is the first thing you do when you take a bus, a train or a taxi. You decide where you want to end up. Since it's pointless to just start driving, moving around and around and only stop when you've reached you're destination. Fun when you're backpacking, but very inefficient when you're not.
So basically, when we develop web-services, we start within finishing as we start with defining what we want. These are the requirements. Mind that the more specific the requirement, the more likely we get what we need. So next we check what it's going to cost to get there. Determining the cost of creating the service will allow us to decide whether it's worth it. We already know how to pay for it, typically it's in terms of time. Then, if all checks out, we request an implementation. There's a lot of different ways to develop a service and we have to decide whether we go for a quick online solution, a more solid standard product, or a custom made solution. It's basically all about the rating of the driver, nothing more. Then we develop. Once we get to our acceptance testing we verify whether the destination is exactly where we wanted to be in the first place. The more stars the closer to what we wanted.

So let's put a little agility in to the mix. The Uber driver is using a navigation tool on his phone to determine where he needs to go and when he strays from the route, the navigation tool will make sure to get him back on track. But the awesome part here is that the navigation is turn by turn, in other words, only at specific points on the route, it will provide input on how to adjust the course. This is what we do as well during the development of products. We have defined points in time to determine whether or not we are on the right track. And just as the customer can tell the Uber driver that she wants to go somewhere else, we can adjust our destination as well. Mind that the customer of the Uber driver can't tell him verbally, but instead has to provide a new destination in the Uber app. Reason for this, is that both the customer and the driver know exactly what the new destination is by using the exact same terminology. And the Uber driver is adjusting his route to get her there. In effect, the customer will tell the driver under what circumstances she's happy to accept the end of the ride, i.e. she's driven to her (adjusted) destination. We do the same, we change our to be developed product, by redefining the requirement and accept the product when the adjusted requirements are met.

Now folding the Uber analogy and the Agile software delivery into a single, stronger, strain of software engineering DNA, we have to look into some additional little tidbits.

For one, to get software delivery in an agile way really to work, you need to make sure that you deliver the features in a way that they are useful, which means that it is best not to focus on functionality but on behavior. This allows everybody to consider the software developed to be regarded as an actor in the business of the company. The difference is that you not only have the basic functionality of the Uber driver to get you at your destination, but you can also define how to get you there by means of non-functionals. So how fast to get you there, whether or not to stay on the highways as much as possible, etc. When describing behavior, the non-functionals are an integral part of the behavior instead of yet another set of requirements, typically those that are left out when discussing the system and only brought in at the end, right after we find out the system is not performing.
Just like we have, often untold, additional requirements for our driver that are typically related to his behavior, we have these as well for our services. And just like we first verify the by Uber proposed driver and cancel the trip when we don't want that driver, we need to do the same with our services. There are always many ways to solve the business service puzzle, but most will be rejected because they don't expose the right behavior.

What's left when you're not religious? What kind of architect can you be?

Summary: As an architect it is often perceived as if you were religious about technology. It should be the other way around, you should be perceived as the single one person that is not religious about technology.

A couple of years ago I was living in Egypt, in Cairo to be exact and this was in the period 2010 - 2013. I had a great time living there and an even greater time working there as Chief Architect of a commercial bank.

Sometime in my second week in Cairo I was confronted at work with the question whether I was a Catholic, or maybe a Jew, or possibly a Muslim, although I didn't really act like one. While stating that I was none of the above, my colleague was obviously disturbed as I really didn't look like a Hindu or a Buddhist. So the question for him was what kind of religion I was part of. My answer wasn't Atheist as I am not an Atheist. My religion is the one that typically has no checkbox in front of it on any form, I'm Divinity Agnostic, or Agnostic for short. There's a set of basic principles that I like to think to be the correct ones to live by. Life's Architecture Principles if you like.

Principles like those that assume that it is bad practice to go out and kill or even harm other people. Like trying to benefit of the misfortune of others, like just taking what you can't afford and not pay for it. Or cheat your way through life, lying about things in order not to be punished, etc, etc. I think these are basic principles that don't or should not require a divine entity in order for one to live by them. I really don't care what god tells you to behave respectful towards others, just do it. Or even care whether or not there is a god. I do believe that you should trust in your own abilities and not depend on trusting in another's abilities in order to succeed.

But the main thing here is that I am Divinity Agnostic. Agnostic for short. I believe in that there are basic principles that one should live by, Architecture Principles. And before things turn out to be all about religion and not about IT Architecture, I'll move on and start all about IT in this same respect.

I'm typing today's blog on my Microsoft Surface PRO 2, using Windows 10, all the while keeping my eye on my Lumia 950XLwith the Microsoft mobile OS Windows Phone 10 on it. And yes, I am kind of sad that I am not playing a game on my Xbox One, also by Microsoft. But instead, I am listening to music from my collection stored on Microsoft's cloud storage offering OneDrive using Microsoft's music service Groove (previously known as Xbox Music).
By the way, I also have Dropbox and Box.net online storage and also Google Drive and Amazon's Drive is there as well.

I think by now it should be obvious that my computing life is pretty much filled with Microsoft stuff. Moreover, my son's laptop is a Dell XPS with Microsoft's OS and my wife's PC is a Microsoft Windows 10 based all-in-one PC. And guess what, for my other son, I've gotten a Windows laptop as well. I promised he would get his own laptop at the start of this school year and promises are there to be kept. That's another one of my architecture principles.

Yup, it is all Microsoft at our home, apart from the two iPads we have, the iPod I have, the QNap Linux based NAS I'm running, the iPod Nanos my sons have, the Pebble smartwatch I have, a black one, and the white Pebble my wife has. And of course, let's not forget the MacBook Pro I'm using every now and then because it's battery life is so much better than most other laptops. Let's not forget about the PS3 I had and the fact that my webservices run on Amazon. Although I use OneNote to take notes, pretty much all other information to be kept is in Evernote and for online backup I'm using Crashplan (I do also have a Carbonite subscription as well).

When it comes to technology, I'm not religious either. I tend to look at what I believe I should be expecting from technology and I choose the one that fits me best. I have an Xbox One because I had an Xbox 360, which in turn I bought because I had the original Xbox. Prior to that I was playing on a Sega Dreamcast, and before that I had a Sega Megadrive, which is the Sega Genesys European edition. Never owned a Nintendo (although I got my kid brother one) not because I didn't like Nintendo, but because Sega had the games I liked best. My choice of Xbox instead of a PlayStation again was a matter of games. Halo sold me by the way. I did get myself a PS3 because it was the best Blu-Ray player for a reasonable price. But I stayed with Xbox, the Xbox 360 for that matter, because the parental controls on the Xbox where better than what Sony offered on the PlayStation, and since I have young kids that like to play, I consider parental controls to be important. A six year old should not be running around with a gun dishing out head-shots online.

I'm just as likely to go for Apple's OSX as I am using Windows and if Linux had been more user friendly back in the day, I would most likely have more Linux around the house as well. The Lumia Windows Phone is there because Nokia send a free Lumia 800 some time ago to me. I think Android is a great mobile OS, but it requires too much effort from a device perspective to maintain. I want to use my smart device, not maintain it.

As with divine entities, technology should not order you around and be the motivation for you to live in some way. You should set out your rules by which you want to live and technology should support you with that. Irrespective of who provides it, unless of course that is important to you. Pretty much the same as with religion. If you think that a particular god should tell you not to go around and kill people, than that is your own choice. Same as whether you think it should be some technology vendor that decides how you should enjoy your music.

Back tot the topic at hand. Being an architect, even when you're serving the shareholders of some company, you should always start from requirements and then select your technology. In case homogeneity is something you think has value (I have an opinion on that, read my post on the topic) than consider that as a requirement.

As an architect, you take those requirements and look for the right tools, technologies or other solutions to fulfil those requirements. Don't get religious about it, but stay pragmatically agnostic.

How you'll fail as an IT Architect when you compare yourself with a building architect.

For the past 18 years or so I've been working as an architect in many areas and industries. During this time the role of the architect has been compared with a building architect. Probably because that is the only architect most people know and not, hopefully, because it is such an accurate comparison.

Architecting a building is so not like IT architecture. There is really nothing that a building architect does that an IT architect does as well. Not even when you're into waterfall methodologies.
The biggest difference is that architecting a building means architecting something fairly static, with a lot of standardization in place and hardly, if any, deviations from standards allowed. You create the architecture and it is build that way, and if you want the exact same building in some other location, you use that exact same blue print. As such, this is more like designing a COTS (Common Of The Shelf) application. The building architect is more like the software designer, or application designer if you will.
The IT architect is doing something entirely different. For one, she designs something that revolves around principles and is typically not much more that a logical cohesion of principles, assumptions, views and visualizations that provide a general outline of what is needed, more often focusing on how it fits in and it interacts with its surroundings.

Okay, so the building architect focuses on how the internal construction will allow the building to be used and how the external part of the building, its face, looks nice in the surroundings. Just like the software designer. The IT architect focuses on how the surroundings fit around the systems. And how generally the internal construction should look like more or less, in order to support the externals.

Let me cut to the chase, the bottom line is that IT architecture is more like, I'll keep you in some suspense for now.

The thing is that buildings, like I stated before, are more or less static. From the inside as well as the outside. This is what the building architect keeps in mind, he needs to create something that will last, that excels in its stability.
IT systems are unlike buildings, especially when it's software, are dynamic, they're organic systems. This is the exact reason why everybody eschews waterfall and loves SCRUM, and even when you love waterfall, you're aware that the system you're creating is dynamic, or rather organic. As time evolves, your architecture evolves with it as it will be bound to be used for different things. Or at least differently as anticipated. Granted, this is also true for buildings.
Fact of the matter is, that once you start architecting a bulding and you're done, that what you created will be build exactly like that or not at all. With an IT system, you know pretty much for sure that it won't, and the longer it takes to build, the more your architecture will be deviated from.

Thankfully, IT architects are not at all like building architects. Or at least should not aspire to be building architects, or believe that they are because of that comparison over and over again. No, IT architects are more like city-planners.

Ever played SIM City, the computer game in which you have to design a city that thrives? You have to designate areas for commercial, industrial or residential purposes. Build roads, or railway tracks and canals. At no one point do you design or build any of the buildings, but in order for them to appear you need to provide power, sewer systems, water and ensure that pollution is not hampering the growth of your city by making sure that garbage is collected, power is generated in an environmentally friendly manner and rescue services are available where probably most needed.
In SIM City you are a city-planner, you have to architect something that is extremely organic. it changes over time and you need to be aware and facilitate growth. You control up to a point how things evolve, but have no control about how buildings look like, except from the perspective that you provide the ability for the game to place a specific building at a specific place. You're architecting.

So, IT architects are not at all like building architects, they're like civil engineers, they're like city planners.

As always, let me know what you think about this. You agree? Leave a comment, I love to hear that others agree with me. More importantly, when you disagree, leave even more comments, because from you're insights, I can learn.

Iwan