37 Things One Architect Knows About IT Transformation

Gregor Hohpe: '37 Things One Architect Knows About IT Transformation. A Chief Architect's Journey'. Apparently the title used to be '37 Things One Architect Knows. A Chief IT Architect's Journey Through a Digital Transformation'. 

Book is broken into 7 parts which in turn are broken into introduction and 1-8 chapters. This is enormously educational book, almost worth it's weight in gold. It might a bit hard to read quickly as it really covers 37 distinct topics, and if consumed to quickly - might be slightly overwhelming. 

 

Furthermore it might be worth to read it twice, because there's plenty of interlinking so to appreciate all that indicated connections, second go through might help. 

 

Overall verdict: highly recommended.

 

 

 

 

---

Personal notes:

1. Architects - some fairly obvious observations what architect is not. Relating to my work place it stresses the fact, that common sfd progression is currently sfd → ssfd → (A)A which is flawed. We need more lsfd and maybe slsfd. We need more people going ssfd → lsfd → slsfd. Also of note - perhaps slsfd should be called staff sfd? In any case architect is not PM for obvious reasons. Interesting suggestion is that Architect is change agent - that they need to enable teams to move fast and show skills complementary to hard skills.
1. Architect Elevator - I heard this analogy in reference several times before reading this chapter (the book with that title is still on a reading list) and I thought this has something to do with elevator pitch. I was wrong. This is fantastic metaphor. Gregor states that the role architect is to travel from engine room at the bottom (dev teams) to the penthouse at the top (upper management) to facilitate flow of ideas and obstructed execution, roughly speaking. There's more to it will mid to lower management sitting somewhere in between and blocking architect. Now the interesting point here is that generally speaking one level of architecture is frequently sufficient with big organizations perhaps needing two: technical architects and enterprise architects. The two architect types can meet in the middle but that's necessary only sometimes. One can wonder at what point IT department is big enough. In any case, one can wonder if 3, 4 or even 5 architect levels are even necessary. I'm persuaded by the picture quite strongly. I'm afraid we have too many architects. Additional points here are about different aberrations (lazy architects sticking to penthouse etc). Word of caution: flattening the building is probably unwinnable battle.
2. Movie star architect - it covers enterprise architect archetypes. All of them are exposing certain aspect of architects job so I will take a v. short note:
• architect should be responsible for building, not designing;
• the all-knowing reference which is almost impossible to pull off
• gardener - meaning you need to spot the weed to remove and the plant to assist; seems fine yet subtle
• tour guide - you don't need to be expert on most of the stuff, but you need to be able to tell a story, knows enough about everything to be trustworthy and sticks with (I guess business colleagues) so they feel they have assistance
• wizard - meaning mostly that you have perception of someone capable of solving anything; double edged sword (I agree with Gregor)
• superglue - spinamy architekturę, techniclaities, requirements and people across organization.
3. Enterprise Architect or Architect in the Enterprise - two competing concepts: to architect the enterprise (incl. business side) or to architect IT on enterprise scale; personally I would stick with the latter, although I can imagine plenty of benefit in someone doing the former. You can find this link, but more importantly, reference to this diagram:
   
   
   
   and alternative from book with examples:
   
   Great food for thought. It essentially tells you on what IT should focus depending on in which quadrant it is. Where are we? If you haven't already asked yourself that than srsly, wtf.
   In any case: 'business architecture defines the company operating model, i.e. how business areas are structured and integrated, derived from business strategy. IT architecture builds corresponding IT capabilities.' This is pure gold. I need to ask BA for that. Furthermore - 'enterprise architecture is the glue between Business and IT archtiecture'.
   Maybe we got it wrong?
   Fundamental point is that even if IT is that business/IT separation is misleading. Even if company's business will never be IT, IT can still drive business. In my mind because everything is digitalized and if you can make transformative change, you can show business colleagues option they haven't dreamed of.
   You can be IT architect working at enterprise scale just by connecting right people on different levels.
   Word of caution: if you explore all the options on enterprise scale, dev team scale and everything in between, remember you're supposed to deliver value, not just have fun.
4. An Architect Stands On Three Legs - good architect needs to have 3 things: skill, impact and leadership. That's it, the chapter goes into some details.
5. Making Decisions - decisions are differentiating quality of architect. This sentiment reoccurs throughout the book and I think it is spot on. Gregor covers a bit of data on how bad people are at making decisions. It resonates well with 'Thinking fast and slow' by Daniel Kahneman, which is also mentioned in the chapter. Conclusion here is crucial, yet not uncommon: job of architect is to delay decision until last possible moment.
6. Question Everything - "5 Whys". Basically delve deep into subjects to break through assumptions and shaky foundations into underlying truth, however distorted. Gregor also indicates what architecture reviews should be - worth thinking whether your workplace is doing that in meaningful way. World of caution: requesting better documentation can lead to painful meetings. Good documentation is not an option.
2. Architecture - in the intro Gregor goes through some nuances of what architecture and architects is and are and what it isn't and aren't. For the most part it is interesting but not necessarily very noteworthy. He makes the comparison I remember from one of his lectures - that architect essentially sells options on the IT systems development. I like the idea but it makes me question if I'm doing my job correctly (then again - questioning is good thing). Two observations: architecture is a matter of making trade-offs (probably good idea to document these) and cohesion
1. Your Coffee Shop Does Not Use 2-Phase Commit - Gregor starts with some observations how starbucks wants and how you can link patterns to software communication. Maybe a bit overextended metaphor but illuminating nevertheless. Exception handling, compensating, correlating, retries, conversations - everything is actually present in Starbucks. Even canonical data model (which of course reminds me of this). Conclusion is that real life is basically asynchronous most of the time so this type of communication should be natural to model real life. Interesting.
2. Is This Architecture? - This part delves into definition of architecture. My take is that the correct definition of architecture is basically useless and I like Martin Fowler's approach (also mentioned here) who says that if definition is hard, perhaps it's worth to focus on defining factors instead. That's good attitude. I think plenty of pointless internet flamewars could have been averted with that approach. For Gregor perhaps the most important defining factor of an architecture is choice (reminds me of Neo's: "Choice. The problem is choice"). That means that even extremely oversimplified diagram can be architectural artifact if it is a record of important decision. That sentiment is so much spot on.
3. Every System is Perfect... for what it was designed to do! - System thinking. Point of difference: 'while popular software architecture definitions focus on system's components and interrelationships, system thinking emphasizes behaviour, viewing structure simply as a means to achieve a desired behaviour.'. The point is quite interesting and gives an architect different lens through which to look at IT systems - meaning the system and architectural presentation of a system will look differently and will give you different perception. Reversing that notion - if you're being offered information on a system, the way it is structure can tell you plenty on what's going on around the system. In my mind - if you do a double reserve (I guess we're in spin = 1/2 situation), you can push perception on a consumer just by rearranging elements that people will see (i.e. the most important part is in the center; there's always assumed meaning behind structure). Furthermore this perception focuses on feedback loops, behaviour patterns etc. This observations can have very meaningful connection to IT systems. Furthermore there is a feedback cycle here of sorts as behaviour patterns influence the usage of the system, but the system influences behaviour patterns. 
4. Code Fear Not! - here Gregor covers the dangers connected to preference of systems that require only configuration rather than coding. While I can understand that it can be a problem, so far it was never a problem I've met so nothing very noteworthy for me.
5. If You Never Kill Anything, You Will Live Among Zombies - zombie is a system that got outdated in time but is still relevant/needed. Actually Google systems are becoming legacy quicker, because the company is moving faster. It is important to plan for obsolescence of a system. It is important to retain ability to change all systems - preferably with agility. The balance of maintenance and operation vs ability to change tells you everything on system and enterprise level. 
6. The IT World if Flat - mostly that's argument about the value of mapping IT landscape in a company. I think that's something I'd like to see. Not exactly sure what level of details it should contain, though? It looks to me like it should be a job of 'enterprise architecture' - whatever that is in given company - to map whole landscape of IT systems. That's plenty.
7. Never Send a Human to Do a Mcihne's Job - basically that's one long argument that you should automate everything everywhere (almost like the movie: everything everywhere all at once). If something takes a lot of time? Automate. If something is rare? Automate. If something is common? Automate. I thought I knew how far automation should go and I was wrong. We need more.
8. If Software Eats the World, Better Use Version Control - basically that's one long argument that software should define as much as possible: network, data centers etc. Everything, roughly speaking. I wholeheartedly agree. 
3. Communication - Communication is very important for architects. Obviously. I was happy to read high value Gregor puts on publishing technical papers because of many benefits. The ability to keep audience excited is tricky. Code is not documentation.
1. Explaining Stuff - it is crucial skills for architect. Worth to remember: remember how far audience need to get to understand what you're saying, set up what you're saying in such a way they can get there, be consistent in details, build up language you will be using and remember this is important skill for architect.
2. Writing for Busy People - writing things down is super valuable. Also you should structure what you're writing in such a way that you can meaningfully browse it. Also first impression matters a lot. Storytelling. Diagrams. Well organized paragraphs. Meaningful colours. The culture of writing things down is lost in my workplace, apparently.
3. Emphasis over Completeness  - diagrams serve a purpose and it's whole structure and presentation should serve that purpose. If you want to emphasize certain problem you're hitting, you can safely discard details of stuff unrelated to that problem. Similarly technical memos serve important role.
4. Show the Kids the Pirate Ship! - presentations should evoke emotions (like Lego Pirate Ship set). Point is most of presentations focus on facts and conclusions. Show context, show purpose, relate content to audience etc.
5. Sketching Bank Robbers - broadly speaking here is comparison of architect to police sketch artist. This chapter could have been part of Movie Star Architect but here we are. In any case - like sketch artist, architect should look for defining factors of a system. Meaningful decisions. There's a part stating what's the difference between arch. sketch and arch. analysis. There's also kind of an inverse point here: ask developers how they see the system and you might zero on a problem. Ah - if you're learning system, don't worry about sketching something wrong. That means you're learning (that's true for most wrongs).
6. Diagram-Driven Design - few things here. One - there's suggestion that if you're making a presentation on s.t. technical and need detailed diagram or piece of code - don't put it in powerpoint. Provide it as a handout (digital handout on teams) and - I guess - reference it in presentation. Marvelous. Bullets are the worst. Some points on how to make better presentations. And to the point. The diagram and the code are never 1:1 but they should influence each other and it is quite possible that by diagraming a piece of software you can arrive at conlcusion how to make that software better. Worth exploring. In the end diagrams can be messy.
7. Drawing the Line - recurring point Gregor makes is that on any diagram, lines are more interesting that boxes and diagrams without lines are probably wrong. There are some usually unwritten rules of diagraming like proximity and containment. Some in-depth points. I like the closing sentence, that you should keep in view only the stuff  that you want viewer to think about.
4. Organizations - trees, matrixes. Matrix organizations are ineffective - effective organizations try to avoid them. Interesting for me as I work in matrix. I'm just not sure whether it is 2d or 3d matrix but the latter is probably worse. Intersting point is that while architects can think about design of system (loose coupling, scaling etc) we don't necessarily apply it to structure of organization. Not that I can influence it but I certainly can complain.
1. Control is an Illusion - point is that there's gap between what happens and what people in charge thing that happens. That means that what they perceive as control is based on false perception and so it is illusion. So in order to have better grasp on what is happening from the top, one at the top has to strive for good source of data from the bottom. Do we have this? Good way of doing this is enabling people to make a call instead of make everyone running to the top. People higher up should convey intention and trust people on the line to make right call. Obviously some alerting is required. By the way that initiative is front line proven doctrine.
2. They dont't build'em quite like that anymore - pyramids. I don't encounter IT pyramids much outside of pyramid of tests so I can't relate to this one. Organizational pyramids - yes but there's difference between communication and decision pyramid and purely organizational pyramid. The latter is ineffective with people hiher up being a bottleneck.
3. Black Markets Are Not Efficient - black market is a pattern when you can't get things done (quickly enough, well enough) in intended channel so you rely on knowing proper person to make a shortcut. That's obviously bad and I can confirm that from experience. Gregor further extends the point - extends onboarding, makes people rely on wrong channels, ineffective processes appear to be good enough. etc. We should relentlessly complain and expose shortcoming of processes.
4. Scaling an Organization - meetings are as bad as synchronous communication in distributed systems. Calling people on the phone is even worse. Email is better. Chat is better but also an alternative. Caching is better (cache meaning instead of repeatedly answering same question, write it down and reference/make available; I'm ashamed to admit I should be doing more of that). Alignment meetings are mostly pointless. Status meetings are maybe even worse. Self service is better. Basically you should scale organization as you would scale IT system.
5. Slow Chaos is not Order - agility is not speed so agile is not fast. Yes. Agile is not an excuse for anything. Impressive pace requires good technique so in practical terms - the opposite for opposite result is what happens. People hide behind ITIL not necessarily doing or knowing ITIL (Gregor asks for strategic analysis of customer portfolio described in ITIL; I wonder if we have one?). Orientation on result does not imply discipline. Curiously enough.
6. Governance Through Inception - standards are important. Enforcing standards where it matters is important. 
5. Transformation - basically not all change is transformation which is fairly obvious.
1. No Pain, no Change! - transformation probably will be triggered by pain that organization have. It takes time, it takes steps. It is hard. It is easy to make wrong decisions in good faith. Beware of relapse.
2. Leading Change - 'The corporate IT equivalent of trying to eat healthy at the cake party is trying to be agile when it takes 4 weeks to get a new server...'. So we're in environment which is hostile to agile software development ways of working. Some cautionary points on how hard making change happen can be.
3. Economies of Speed - Digital companies are not 10% faster. They are 10x faster. Or orders of magnitude faster. So should we. They were 100x faster a decade ago. The switch from focus on efficiency to focus on speed is hard. Because it can be perceived as less efficient. 
4. The Infinite Loop - Build - Measure - Learn. Classic companies are bad at this but luckily we might not be that bad.
5. You can't fake IT - Basically you need to put effort and money to transition into fully digital company. Digitalization can happen in steps.
6. Money can't buy Love - It is about building competencies and culture inside instead of contracting it. In this regard we are where we want to be.
7. Who Likes Standing in Line? - If you perceive queues in organization, something is wrong. Because why you wait 4 weeks for something that takes 4 hours, tops? Business Activity Monitoring is something IT should look at all the time.
8. Thinkgin in Four Dimesnions - take time into account. Quality vs Speed is not 1d - it is 2d with a curve you can adjust.
6. Architecting IT Trasnformation  - emphasizes need for digital trasnformation.
1. All I have to Offer Is the Truth -  digital transformation is a must. You should sound alarm if your company is not doing it because fate of Titanic can happen very soon. The benefits of being digital companies are immense but not necessarily obvious from the first look. Digital disruptors attack weak spots - not the whole business model.