Step 1 out of 10: RFI
Architect. This word sounds so mysterious. So mysterious that to understand it you are almost forced to add something. Like “System Architect” or “Program Architect”. Such an addition does not make it clearer, but for sure adds weight to the title. Now you know – that’s some serious guy! I prefer to make undoubtful and around 10 years ago added to my email signature “Enterprise Architect of Information Systems”. It’s a powerful perk. Like “Chosen One”. With architects it is always the matter of naming, you know. Maybe that is why the only way to become an architect is to be named as one by others. Like with vampires. One of them has to byte you! That is probably the easiest way to earn the title as there is no degree or school to grant you one. And if there’s a troubling title, somebody’s making a trouble, and the only reason for making a trouble that I know of is because you’re an Enterprise. Huge old and complex multinational corporation. Like a one-legged pirate. Strong and scary, but not a good runner. You own your ship, you had good days, you have some gold, you need new ways.
To get to new treasures and avoid losing the second leg to piranha regulators and local business sharks swarming waters near every enterprise ship – every pirate has a map. The map is a list of major features and requirements in desired order and priority.
With the map, we know what our pirate wants and now we can get there in some SAFe way. So, we need a path. A thin red line. Simple and vivid. Not colorful labyrinth in Mondrian style. Architecture is not about art and aesthetics at all. Don’t get me wrong, if I were to build a house, I would not be looking for a gray concrete box, but something with an exclusive style. But exclusiveness comes with a price tag. So even G-man with a briefcase full of gold will ask for the trends and the vibe, but only within the predefined budget. Architecture is not a masterpiece of art, but an engineering paradigm.
Without an architecture - any solution is good if it answers immediate requirements. But once you have a line – you can evaluate how good the proposed implementation is, based on the distance. And the main and only purpose of architecture is to get you through a maximum number of features "without additional development". Free lunches are always easy to sell.
The treasure hunt has its pace and phases. We will start from the initial phase prior to the actual order and go step by step to maintenance and end of life.
Now we are not in the gold rush yet. We only heard the rumor of the treasure and a preview of the map (RFI). You are one of the stakeholders on the corner of the round table. The crew of your ship evaluates the consequences and profitability of the treasure hunt. In theory, all you need is a red sharpie and a whiteboard. But we all know that no matter how good you are in red lines when it comes to implementation it will be done in parallel-perpendicular transparent green line in the shape of a kitten. At this step you KISS your architecture and details and get something colorful and very generic – a sketch.
Before beginning a hunt, it is wise to ask someone what you are looking for before you begin looking for it. We want to document of “what” from existing high-level requirements we can get. Are you already thinking about distribution tax and how to fit everything in less than 42 micro-services? Don’t jump the gun. For now, let’s focus on block diagrams and use cases. We need to figure out the main cases and actors. Of course, you can use UML. The most wonderful thing about being a UML expert is, that you are the only one. And we are doing this chart for our presale team on the captain’s bridge. I usually just define some layers to pin scenarios and show the flows. A red velvet cake with m&m’s topping.
An expert as you are will sure note that this non-technical stuff should be a job for a product department running the galley. But if you are an expert, why bother reading this, as you already know that the first sale is an internal one. You need to pitch architecture to your management. And they know it is more fun to talk with someone who doesn’t use long, difficult words but rather short, easy words like: “show”, “pay”, “get”. What is important now is only to define some basic blocks or even just a number of these blocks. Things that you see as constants or with minimum volatility. Like defining a number of walls and supporting structures without stating the materials.
Agreed on the wall? What will be the next most important thing for your customer? The color of water pipes! The thing that faces up only in case of critical failures. Obvious, isn’t it? Big one-legged enterprise digs glossy and trendy stuff. He wants to be spoken like that fitty energetic start-up guy. Risk taker and a winner! But stable, verified and trusted. To impress you have to use buzz words. It is about time to lift and shift our red-velvet to the clouds and spice it up with those micro-services. After the previous step (business verification) we can assume whether it will be some closed loop system, will it be deployed in a public network, is your environment discrete, estimated number of clients, lifetime and so on. It does not mean that there will be no surprises. Customer may define that system has to be in a cloud with zero footprint on a terminal, but fully operational in offline. Or request that everything will be implemented as standalone micro-services deployed in one monolithic application. Or full data integrity is always available distributed system. Thanks, cap Obvious! I had a pleasant experience of finding out that customer wants to operate delivery drones in an African region with navigation in a cloud in the areas without any connectivity and the lowest ping to the cloud in good areas around 300 ms. It is easier to make a cat laugh than a customer-facing engineer.
The task is to pull out a set of shiny icons with trendy technologies. There is no silver bullet, so shoot with whatever you are good at. Probably you will not be allowed to hire a new team to match your dream. So, dream with the stack you have. Enterprise projects may live in production for years and probably will be in dev for a couple of years too. It is not a one-man show. You must work with steady teams and they come with existing knowledge and expertise. If you have 5 back-end teams of senior Java developers, mastering Python is not something you should consider. All you need is to use existing blocks and connect your walls with Penrose stairs.
Having said that you still have a choice and should use it. If you have a lightweight client application without complex UI/UX you have full legitimization to go for the technical edge. The front face of the system is the most volatile and short-living component. Just like front-end frameworks. If React is hot right now – take it and get one expert for your team. Back-end on the other hand requires you to choose technology that will be mainstream in 5 and 10 years from now. That is why Java and .Net rule this world. If there will be microservices then you can declare that each team is “free” to choose. Democracy at its best. You already know your teams and they have a limited tech stack, so there will be no surprises. Just mind the size and the need. I know it is popular to think that a microservice is always the right size and always appropriate. If you do not have a centralized system and no need for fan-out dynamic scaling, then maybe you should consider alternatives. You see, the team that was supporting monoliths last 20 years will not be happy in the role of zookeepers. They do not always understand what it means to manually deploy and support a private on-prem distributed solution. One cannot just get there and replace the “thing” or connect with RDP to “correct” the values directly in DB. And anyhow they will do it through some jumper in the production environment to make a subtle change, missing the point that it was only one of 12 databases. Sweet way to say goodbye to your weekend.
Short off-topic. An enterprise customer is like a whale in the ocean. Just not that elegant and with several heads with slowly progressing dementia. But corporations serving and feeding on it are just the same. They have an old connection with customers. Once they were vendors of the hardware and look at the software through industrial age glasses: make a prototype, adjust to mass production and flood the market with your product at no time. “What do you mean rollout is not a step, but a process? Just copy-paste it to all stations!” “Why does it work differently on those machines – it worked fine in the lab!?” And there will be many lessons to learn. Not only do you need to push the solution and sell it within your own team, but make sure your company is ready for it.
Now this time we need to make the same cake with a different bake. We focus on technology. Boundaries and connections are not the point here. Just make sure you can justify the choice of each icon. This is the first glance at upcoming development expenses. Licensing, experts, mentors, support, sizing and so on. Many colorful images in this mosaic will make your potential customer happy, but expenses are the sad story. Some things are a must though. No matter where and how, but you must mention Kubernetes. Even if there is no scaling or you develop some stand-alone desktop application. Push to automation tests as part of CI-CD. It just has to be there. Add Docker containers as a perk. You know it comes in a bundle, but your customers usually don’t. Do not forget about security – add an HTTPS stamp.
Obviously, after a long and hard approval of the architecture solution, you will be following the line of least resistance. Reuse of previously approved patterns and designs on a different scale. Mandelbrot style blueprints.
I'll cut it here and will translate the next post in a week or so.
TLDR: we are on the very first step - not a project but an idea. No detailed requirements. Everyone is evaluating the situation and potential. Your goal is to assist in understanding high-level expenses and obvious risks. To not dive into the technical solution. Speak with each party n their language. With sales talk about innovations and vibes. With development about existing and new tech stacks. With managers about risks and timing. Finance thinks in resources (new hires, DevOps, hardware, software licenses).
Zipped version:
No project - no architecture ( only high-level design )
Map the way (name flows and technologies)
The cake is a lie (the best innovations are the aged ones)
the
