Business Driven Solution Architecture

In this symZone article, I would like to invite you to take a quick look behind the scenes of Secure Service Hub (SSH) and show you how we develop the perfect application architecture for ever-growing (business) demands to modern software solutions like SSH. For us, the decisive success factor is the consistent alignment of the software architecture with the business model and the associated value proposition. This is neither a new software design pattern, nor does it replace valuable and meaningful patterns such as BDD or DDD (Behavior/Domain Driven Design), which we also use. Rather, it is a philosophy that we have embedded throughout the organization and to which everyone is committed.

Technology is fun, challenging and motivating at the same time, but should never become an end in itself. The increasingly shorter cycles in which new concepts of software architecture, frameworks and tailored programming languages appear on the market lead to an increasingly complex landscape of solutions. If you look at the different options relatively encapsulated and in the context of successful application cases, they are usually always valid and value-adding. The great danger lies in the use of concepts and technologies for reasons such as good experience in previous projects, existing know-how in the company or current hype in the market without considering the most important aspect – the business impact.

In today’s world, it is no longer the technological hurdles that define the limits of what is possible – almost any functionality imaginable can be implemented with appropriate technologies such as AI, blockchain or virtual reality. BUT: It is the view of the business model, customers, industry, etc. and the requirements derived from them that should have a decisive influence on the architecture and technologies used in a solution.

So, we must avoid designing technology-driven solutions, as it unfortunately happens in many cases, regardless of how much experience the development team has or in which domain the solution is to be deployed. When designing and implementing Secure Service Hub, we were guided by a “Business First” approach.

Let me explain this approach using three selected value propositions that we want to offer our customers with SSH:

• We keep the market entry level and total cost of ownership as low as possible.
• We deliver innovation in fast cycles and without impacting the business.
• We provide a competitive advantage through optimized and easy vertical and horizontal integration into the IT infrastructure.

So far, so understandable. But how do we draw the corresponding technological and architectural conclusions? The first step is to derive product requirements from the value proposition – and not yet technology or architecture requirements. Our three value propositions can be summarized into one overarching requirement: “The need for speed and agility.”

No promising conclusions can yet be drawn from this requirement. In the next step, we now break this requirement down into smaller and more precise user stories:

“As a customer I want…

• …a dynamic billing model to pay only for the services used (Pay-Per-Use) to have low investment cost.”
• …a solution that provides external operation and support to save internal cost and resources.”
• …a solution that delivers innovation quickly in order to react to change in my business.”
• …a seamless integration into my heterogeneous IT landscape to leave existing and established business processes untouched.”
• …

Many more points could be added to this list. However, it can already be guessed that these types of concrete user stories (they describe the WHAT) already contain very valid and valuable hints about architecture options and deployable technologies (i.e., the HOW). Here are some examples:

• Pay-Per-Use business models can be optimally implemented (for both sides) in a cloud-based SaaS (Software as a Service) architecture, as resources are shared and can be scaled quickly and automatically during peak loads → compared to an on-premise solution on dedicated servers / VM’s.
• A quick and non-disruptive rollout of product increments is possible with a microservice architecture managed by Kubernetes cluster, as this enables the decoupling of services and the implementation of appropriate rollout strategies (e.g. rolling updates) → compared to a less complex monolithic approach.
• The API-First approach ensures that the most important (or even all) product functions are available through an API, thus providing optimal support for integration into the customer’s IT → compared to a more closed architecture that for instance promotes a corporate customization and consulting business model.

As always, there are several possible solutions. That’s why it’s important to rely on technology and architecture experts designing a holistic solution that delivers ultimate benefit to our customers – yet also brings a bit of fun to development and operations.

In my opinion, the approach to solving the architectural question is quite simple and obvious. It is the answer to the question “For whom and why do we develop our product(s)?” We develop them for our customers!

Accordingly, all decisions regarding the architecture and the technologies used in a solution should be based on the premise that they contribute to maximizing value for our customers.

I hope I was able to give you a little insight into the way we at symmedia handle the software architecture and the use of technologies.

Stay tuned for further details and more insight into the SSH architecture!

Best wishes,

Marius
Chief Technical Officer

PS:
Would you like to know more about symmedia’s application architecture?
I’m happy to take your questions: burger(at)symmedia.de