Architect. This word sounds so mysterious. So mysterious that to understand it you almost forced to add something. Like “System Architect” or “Program Architect”. Such addition does not make 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 year ago added to my email signature “Enterprise Architect of Information Systems”. It’s a powerful perk. Like “Chosen One”. With architects it is always a 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 second leg to piranha regulators and local business shark swarming waters near every enterprise ship – every pirate has a map. Map is a list of major features and requirements in desired order and priority.

With 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 esthetics 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 requirement. But one 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 though 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 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 preview of the map (RFI). You are one of the stakeholders on the corner of the round table. 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 – 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. You had already started 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 main cases and actors. Of course, you can use UML. The most wonderful thing about being an UML expert is, 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 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 define 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 face 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 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 previous step (business verification) we can assume whether it will be some closed loop system, will it be deployed in 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 cloud with zero footprint on 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 in always available distributed system. Thanks cap Obvious! I had a pleasant experience of finding out that customer wants to operate delivery drones in Africa region with navigation in cloud in areas without any connectivity and lowest ping to the cloud in good areas around 300 ms. It is easier to make a cat laugh than customer facing engineer.

The task is to pull out a set of shinny 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 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 light weight client application without complex UI/UX you have full legitimization to go for the technical edge. 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 micro-services then you can declare that each team is “free” to choose. Democracy in its best. You already know your teams and they have 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 micro service is always the right size and always appropriate. If you do not have 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 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 production environment to make a subtle change, missing the point that is was only one of 12 databases. Sweet way to say goodbye to your weekend.

Short off topic. 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 old connection with customer. Once they were vendors of the hardware and look on 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 it works differently on those machines – it worked fine in the lab!?” And there will be many lessons to learn. Not only you need to push the solution and sell it within your own team, make sure your company is ready for it.

Now this time we need to make same cake with 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 on upcoming development expenses. Licensing, experts, mentors, support, sizing and so on. Many colorful images in this mosaic will make you potential customer happy, but expenses are the sad story. Some things are 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 https stamp.

Obviously after a long and hard approvals of architecture solution you will be following the line of least resistance. Reuse of previously approved patterns and designs in different scale. Mandelbrot style blueprints.

I'll cut it here and will translate next post in a week or so.

TLDR: we are on very first step - not a project but an idea. No detailed requirements. Everyone is evaluating the situation and potentials. Your goal is to assist in understanding high level expenses and obvious risks. To not dive in technical solution. Speak with each party n their language. With sales talk about innovations and vibes. With development about existing and new tech stack. With managers about risks and timing. Finance think 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 (best innovations are the aged ones)