A few days ago, I found myself in a discussion with a group of university students. The topic eventually evolved around enterprise architectures. This post is the summary of this conversation. OR: it is about how I stopped worrying about Enterprise Architectures and learned to care about teams instead.
The age of creative destruction – and the smoking gun is information technology
The term was coined by Joseph Schumpeter in 1942 and it goes like this: The "process of industrial mutation that incessantly revolutionizes the economic structure from within, incessantly destroying the old one, incessantly creating a new one.“ I used the average lifespan of companies on the S&P 500 index as an example. It has been dropping since the 1980’s, that is a new member can get into this prestigious club faster than ever before but can get out of it at similar speed. (footnote: those who dropped out usually don’t stop falling at this point.)
A collision of views: on the one hand IT is becoming a commodity (see Nick Carr’s IT doesn’t matter) while it is the force (accompanied by new business models) that shakes industries in a few years (see Marc Andreessen’s Why Software Is Eating the World). I remember the BlackBerry CEO’s Famous Last Words at the 2007 iPhone Launch: 'We'll Be Fine'.
There are two consequences of this shift: The business demands an IT that can respond to challenges within days rather than months as it did before. This requires an underlying infrastructure that can grow or shrink within hours and can scale to “infinity”. The trend is clear, just have a look at the chart below on IT infrastructure spend. (source: Mary Meeker’s keynote on the INTERNET TRENDS 2017 conference - slide 181.) Chances are you will have some flavour and combination of IaaS/PaaS partially or entirely at a public provider within 5 years.
The other no-brainer is the front end: Many years ago, my team was tasked to protect the market share of Internet Explorer in Hungary. (a bummer in retrospect.) We used http://ranking.gemius.com/hu to track progress and we could not avoid noticing that it was not just IE under fire, but Windows as well. Fast forward 6 years and we arrived at another chart that was unthinkable just a decade earlier.
The picture may not be this decisive if we filter in the time spent on the web but anyway your stuff has to have a mobile frontend, you are even likely to follow a mobile first, desktop second approach.
The last step in my less than sophisticated Enterprise Architecture pitch was the stuff between the servers and the mobile front ends: containers and microservices. I ended up with something like this:
Since the topic was Enterprise Architectures I needed “a chart” on the subject. I was thinking about a TOGAF chart, then it downed on me that this thing was hanging on the wall (printed in A1+ size) of any decent enterprise architect. The other certainty was that the system envisioned on this picture was never built. I had another picture on my mind: the elephant in the room, that these frameworks forget about the real thing: the people who design and implement this architecture.
Conway’s law
There are forces that shape your enterprise architecture that has nothing to do with technology. One of them is the Conway law: “organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.” The law is based on a sociological observation. It is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it. Now get this: … “the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise.” In case of ACME (a strictly hypothetical company) I have seen cases where fragments of a dev team spread over 3 continents (say two guys in each time zone, due to tactical hiring practices driven by speed and sprinkled with cost considerations.) This is no surprise that this setup produced scary designs and very high attrition.
Fred Brooks made this observation in the Mythical Man-Month in 1975: “Because the design that occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.” So have a look at the structure of the key stakeholder org units and the dev team itself before you start your system design.
So how can we escape the technical design doomsday with non technical measures?
- Don’t use technologies that require scarcely available specialists! Linkedin is a good starting point: if you find less than 300 people in Hungary who refer to a given technology in their profiles, this is a safe bet to drop it, half of them are sales or PMs who dealt with people who knew this technology, the other half will not move. (Try it with keywords like Erlang.)
- Avoid prima donnas! I had a case when two of these folks started to disparage the design of each other in front of the CLIENT! (right after pointing out that the operations team members (of the client) had the brains of a midget.)
- Create small teams with multi-faceted skillsets and the shortest possible communication paths. Make sure that the organization is compatible with the product architecture!
- Collocate your testers with the dev team: a remote testing team in India – while certainly the cheapest - many not be the optimal solution.
- Be prepared to homomorphism: Organizations with long lived systems will adopt a structure modelled on the system. (particularly true for mainframe based systems, a state within the state, the secret of the longevity of these beasts is that this is even more expensive to get rid of them than to keep them.)
- Go with short release cycles - give something to your client soon, don’t let them change their mind or sponsor.
- Keep in mind the theory of constraints: Constraints will define the overall throughput of your dev team. Identifying the bottlenecks is the first step in improving the throughput. Use KANBAN.
All the best Guys, it was great talking with you! If anything sticks from all of this above, be it the movie:-).
References:
Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb (1964)
http://www.econlib.org/library/Enc/CreativeDestruction.html
https://www.innosight.com/insight/creative-destruction/
https://a16z.com/2016/08/20/why-software-is-eating-the-world/
https://hbr.org/2003/05/it-doesnt-matter
BlackBerry's Famous Last Words At 2007 iPhone Launch: 'We'll Be Fine'
http://dq756f9pzlyr3.cloudfront.net/file/Internet+Trends+2017+Report.pdf
Using the TOGAF® 9.1 Framework with the ArchiMate® 3.0 Modeling Language
