Enterprise Architecture: Nobody likes architects…
What makes you a good architect in the enterprise world and how you can achieve agility in such a fragile environment.
It’s been a while now since I’ve routed my career path away from the first lines of the software development battlefield and went on a journey to architecture. Still, it is hard for me to understand what exactly the architect role in the corporate world should be and what exactly the role of the architect is in an agile environment. Who is The Architect?! I guess you’ve heard the saying that the architect is an ex-developer, who can code no more. But that’s just some funny talk. What is the serious answer here? You see, The Architect is a pretty old role in IT world, which was a very important one in the good old waterfall way of working, where software architecture brought to the industry concepts from the buildings architecture, where it all starts with a sketch, then goes the budgeting, stakeholders’ approval, project planning and execution. A whole bunch of frameworks on doing software architecture and managing IT in the corporate world were crafted — TOGAF, COBIT, ITIL, all trying to explain in detail what the role of IT is in the business processes and where software architecture should lay on that picture. But in today’s reality with the agile boom these heavy frameworks don’t really fit well to the “embracing the change” thing and to the faster feedback loop, that is required in order to change a solution as early as possible.
The small office building
Let’s imagine a small company developing a very successful online software, hosted on the cloud. The company has a team of 20 developers, business analysts and QA specialists in total and about 6 business-oriented guys covering management, finances, marketing and retail. All employees share the same small, cozy office building on a quiet street. Any other activities on running the company like HR, accounting and legal are outsourced. In this setup, an agile way of working will make a perfect fit and the main reason behind would be that almost none communication boundaries exist in the organization. It would be a piece of cake for the developer to catch up with the manager’s real needs and goals, while both folks accidentally meet in the kitchen, where they went to get a cup of coffee. Do you need an architect? No, the architect role should be executed by the developers themselves. They know perfectly the product and the business model as well and have quick access to the management in order to do synchronization.
The Enterprise Scyscraper
In big enterprises, however, such direct communication would be rather impossible. Gregor Hohpe crafted a great idea in his amazing book — “The Software Architect Elevator” [1] about the “enterprise skyscraper”. You can easily imagine any big company as a tall building, where the top management lives in the penthouse, on the middle floors are all the business layers of the company led by an army of senior managers. The IT guys live down in the basement, running the whole building, powering it up with electricity while riding their fancy IT dynamo bicycles (or whatever they are actually doing down there…). In this setup the architect is described as the officer running the elevator in the skyscraper. His role is to go up and down all the way between the basement and the penthouse. He or she needs to understand both the goals the management is pursuing from one side and the IT concerns about network infrastructure or software changes, which will have to be applied to satisfy the management needs. Higher the skyscraper, harder that task will become, because on the middle floors there will be a lot more levels of businesspeople, whose opinion will have to be taken into consideration. Because in big enterprises high management has knowledge only on macro level about the company business and the middle floors’ inhabitants are the actual business drivers, with whom an architect should synchronize his work. This is exactly the reason why in big enterprises different types of architects also exist. The elevator serving the penthouse and the top 10 floors of the building is run by the Enterprise Architect, middle floors are served by the Solutions Architects and the basement is for the Software and Technical Architects. Somewhere in between you might even have some Chief Enterprise or Solutions Architects. Why? Because it will be impossible for a single person to go all the way up and down on the elevator in this huge building.
Aside from the abstraction, some more realistic explanation: the architect should speak languages, that two very different communities use — the management and IT. In the big enterprises bosses are never deeply involved into IT problems and as for the IT - the complexity is so huge, that most of the time the folks there would stand against any demand for change. The role of the architect would be to clearly understand the management vision from one side and the IT concerns, as I already said, from other. So, from management perspective, in one perfect world, the architect should be a business guy, who has vast knowledge on IT and from IT perspective - the architect should by a top-notch developer for example, who has access to a direct phone line with the management. The actual situation rarely is that perfect. In most cases, the managers see the architect as an IT guy, who doesn’t fully understand the business language, but instead, is using too much IT terminology and is sometimes annoyingly fighting against business driven changes in the IT landscape. The irony is that the folks from the basement also don’t look at the architect as being a part of their own community. He or she is rather closer to the management in their eyes. I love this quote from Hohpe’s book:
“When IT folks meet an enterprise architect, their initial reaction is to place this person high up into the penthouse, where they draw pretty pictures that bear little resemblance to reality.” [1]
And if that situation is ironic, what about this statement: If neither the management, nor the IT guys like you very much in your architect role and each of them see you as an outsider, a proxy of the other party, that means that you are doing fantastic job as an architect! Contrary, if the management feels you fully as a habitant of their penthouse — a fellow lad embracing the role to pass the orders down through the elevator, then you maybe have lost connection with the IT folks and no longer understand their real problems. At the other extreme, if you are way too beloved by the ITs for standing with a shield before them, fighting back all the management demands as a true Leonidas standing against the armies of Xerxes, then you obviously lack the skills to communicate with businesspeople and negotiate with them, which are crucial skills for an architect in the enterprise environment. Your job as an architect is to find balance. And that is a damn hard job. To achieve this, you must be very good psychologist and to try to understand what peoples’ decisions are driven from. You should try to stay close to both sides as much as possible, although you will be riding the elevator all day long and you probably won’t have enough time to stay up or down as long as you’ll need. To shorten the distance to both sides, it is very important to you when presenting some kind of architecture statement document to always think of what your current audience is and to prepare different versions of your docs. Use the IT terminology only when presenting the solution to the developers and try to explain them why the change is crucial for the management. When talking to the manager, keep the information very high-level and focus on business drivers and obstacles, but try to explain any IT concerns, that might have impact on the solution. Do not try to please both parties at all cost. A little hatred from each side is crucial to help you not dropping an end of the jumping rope, that you use to keep yourself fit.
Being Agile in a Fragile Environment?
Where is ‘The Agile’ in the picture? I can hardly imagine pure agile in an organization working like one big skyscraper. In big enterprises the IT infrastructure and software landscape is really complex and changes could be very hard to handle. If something is so fragile, how can you be agile at all?! I assume here a SAFe advocate will raise a hand, but I am not really sure, that their beloved framework will make it SAFer to handle this complexity and fragility. You see, all those scaled agile frameworks like SAFe are just like putting sports car tires on a liner bus — you won’t make the liner move any faster. Enterprises are heavy structures. Decisions there are hard to take as you have too many layers to communicate them with. Agility is possible to be applied on some divisions within the company, but there is no common formula or framework to solve that for you. SAFe for example, to me looks more like a water-scrum-fall type of methodology. You have a huge funnel of planning of the architecture community on the backlog entrance, then you do the actual job inside the ‘agile’ teams using scrum iterations, but on the end of the production line you have again a heavy structure, the so called “Release Train”, which synchronizes all the work that every team has done within the sprint in a try to assemble one big common release. Sooner or later you will find out that you cannot speedup the whole process, being agile only in its “middle” phase, when you will have to do a massive “waterfall”-ish job in the first and in the last phases. It’s all about way too much planning from one side (which is exactly what we did back in waterfall times) and less “doing”. And this is not agile at all. We should not forget that having such a heavy framework, dealing with the organizational structure and processes, you are losing the main path to achieve agility — care for people and interactions before processes and tools. Agility isn’t about frameworks after all. It’s about openness to change. Choosing SAFe can be an agile approach as far as the team is empowered to remove it when they see it’s not working for them anymore.
As for architects in the agile world — architects are not needed in flat, real agile organizations, where no communication boundaries between developers and managers exist. In the corporate world, however, architects usually are needed to act as the glue between the two edges, to go up and down with the elevator and to find the balance. And architects in enterprise world today must find a way to achieve agility. They must ride the elevator on more accelerated speed, to stop doing tons of massive architecture documentation and instead, to speed-up the feedback loop in order to be open to changes in either management’s needs or in the IT concerns. Architects must stop looking at their job as: write down full architecture statement, negotiate formal approval, pass to the IT and wait for the results; but instead: collaborate, break the solution to small particles, let the team build some of them, analyze the result to find out any obstacles in the solution, change when needed, iterate.
Thank you for reading! Wish you happy elevator riding and hope you get a bit hatred from all sides, but just as much as needed to know that you are doing a great job!
Miroslav Yordanov
Dec 2022
____________________
[1] “The Software Architect Elevator”, Gregor Hohpe, 2020 O’Reilly Media
