Technology != Architecture

“Spring” is not a valid answer to “What’s your architecture?”

Like many, I glom on to specific technologies, usually something new and shiny. The world just keeps giving me more and more awesome technology squirrels to look at. I’ve gotten pretty adept at fabricating the necessary architecture drivers to give me the desired technology implementation. This is so wrong. Now, some of the architecture drivers actually make complete sense. And all of them are recognizable and so they’re hard to refute, at least completely.

There are several things in play here, including “shiny new.” Docker is a great example. This is a solution to a specific problem and a really amazing one at that. But Docker should not even show up directly in an architecture diagram, while many of the things it addresses definitely should. I’m not even sure containers show up, because that tips your hand too much. What about micro services? Not sure either because isn’t that mostly about an implementation strategy?… This is getting at least confusing and probably annoying.

So let’s take a step back and think about what our architectures address, how we communicate them, and how we design and implement from them. Architectures show

• major moving parts and how they interact;
• the smaller moving parts and how they can work independently;
• how important nonfunctional requirements like security and scalability are implemented;
• how external integrations are implemented.

Really not much more. We should be able to validate the architecture with all our stakeholders, including

• Network Operations, who needs to confirm connectivity and security;
• Developers, who need to create designs and implementations that render the architecture;
• DevOps, who must be able to deploy and maintain the architecture;
• QA, who needs easy access to internal components;
• DBAs, who need to verify database access and design.

We can see that things like Spring, Docker and Amazon Web Services are not in the mix at this point. Release engineering and DevOps can greatly influence the specific choices here. In fact, they may own them. They may also declare that an architecture does not make the grade for repeatable deployments, and so on.

At Rue, we live with legacy codebases from many turning points in Rue’s history and at least as many ways of doing similar things. An abundance of Oracle stored procedures is not the only choice now. Neither is generating a database schema that is compromised by the idiosyncrasies of a specific ORM. Our incremental approach to improving Rue’s architecture guarantees we will continue to run a mix of languages and architectural philosophies for some appreciable time to come. Many of these legacy components have implementation quirks as well as overarching architecture limitations. Our first inclination might be to “squirrel!” a specific technical deficiency, like logging, in a single component instead of fixing monitoring and maintainability for the whole system once and for all.

But what if we could also define architectures that had the feel of shiny new? Then we’d all be happy. Our CTO, Anthony, has specifically set us that challenge. Thinking about things that way, we can quickly start to identify opportunities.

• An architecture defined in terms of independent, composable components has some pretty remarkable properties like scalability. Wouldn’t it be shiny new to have a software system where the number of concurrent users is not a concern?
• A data pipeline architecture defines components where the output of one component can directly become the input of the next, and so on. Our analytics platform is architected this way, and that lets us configure and specialize much more easily. I’m quite sure there’s shiny new in that too.
• An architecture that emphasizes services rather than specific implementations allows us to replace pieces as we need without ruining anyone’s day. When we replace our creaky Order Management System, for example, we will make sure we capture core services first and direct traffic to that abstraction. Being able to relate parts of something as fundamental to Rue’s business as OMS without stopping the world will delight the business.

There’s absolutely nothing new at all here in terms of patterns. It’s just a redoubled determination to keep things simple. Then the thrill comes from creating something that over-delivers business value just from being able to respond with “yep, we can do that.”

In this emerging architecture, we’ll be explicitly reaching out to collaborate in new ways with

• NetOps to leverage solutions that abstract away the distinctions between on-premise and PaaS;
• DevOps on continuous delivery of independent components;
• QA on making downstream environments indistinguishable from production;
• Development on designs and implementations that make all this possible;
• DBAs to create databases and schemas that match the business first, our ORMs second;
• Business Owners to push audacious nonfunctional requirements.

Let that be our shiny new.

Originally published at ruetech.io on February 11, 2016.