Based on which side of maturity timeline the market is in, either technology drives business or business drives technology. In an immature market such as the IoT market, technology typically drives business. Such a market is a pioneer’s market. Here IoT product businesses are trying to convince the customers that there is an advantage to installing sensors and connecting them to software products. In a highly mature market such as order management, material management systems, transportation management or warehouse management i.e., the back-end operations product market, typically, business drives technology. In such a market, customers know what a system can and cannot do. They typically tend to ask for features as opposed to the pioneer businesses in which the businesses are trying to convince customers that they need a feature or not. In either case, it should be remembered while it is the business that earns the revenue, profits gets driven by technology, since technology becomes a huge cost factor in the equation. It is necessary to keep the costs of development low, to increase profits.
In a technology driven market, it is all the more important to drive costs down since customers are expecting you to bear most of the cost of research or provide huge discounts to try out new technology. Yet, in a business driven market, customers are unwilling to upgrade products just because technology has been upgraded. But, upgrade of technology is a must, else over time the product falls back on cutting edge technology and is still working with age-old problems again driving cost up. This means that businesses need to find how to amortise the cost of such an upgrade from existing or new customers. To add to this mix, the SaaS market has driven the pricing of software product offerings way down, starting at a very nominal or free offering. In such a market, even a comparison of the cost of R&D to customer pricing is not possible. Amortisation of costs usually takes years rather than months. Hence, irrespective of the market, driving technology costs down is a absolute must to survive in the current software product market space. Architecture has a direct impact on the cost of development, deployment and maintenance of a product. To understand why, we need to look at what architecture really means!
According to wikipedia, “Software architecture refers to the high level structures of a software system and the discipline of creating such structures and systems”. Given such a generic definition, what is recognised as architecture varies widely. The meaning of product architecture varies based on who you are talking to. MVC or model-view-controller is called architecture, microservices is called an architecture, web services is called architecture, SoA (or service oriented) is called architecture, then there is event driven architecture, there is complex event processing architecture and so on. The wide latitude of concepts that are termed as architecture is pretty confusing. To add to all the confusions, there are design patterns and architectural patterns and many more terminologies that confuse even the best of technologists. But, irrespective, what is important to note is that architecture or “defining structures” has a role to play in the entire lifecycle of the product. The lifecycle of the product starts with functional definition, development, deployment, maintenance and enhancements and this cycle continues till the product is taken off the shelf. It is important to note that the product needs to recognise and follow different architectures at each and every phase in this lifecycle. Functional definition has to end in a functional architecture, design has to give a development architecture and deployment architecture. Most times it is expected that a product has only one architecture and hence these different architectures are mish-mashed into an an all encompassing architecture and put in place which falls apart with the first test of time.
Each and every architecture impacts the cost associated with a product sell and the time to market of the product. Functional and development architectures define whether you are doing an incremental functional design and development as much as possible as opposed to re-working over and over again on similar functionalities, while deployment architecture directly impacts the cost of resources used to host and provide support for the service to the customer.
The main aim of choosing an architecture needs to focus on increasing agility and decreasing wastage and focus on customer needs and business as opposed to focussing on using newer technologies and incorporating the current fad existing in the market.
Functional Architecture
The functional architecture puts in place the structures to define how the functionality of the product has to be designed, both current and future. For eg., “one-click ordering in Amazon” for shopping is a functional pattern. This architecture defines how the functionality can be used by a customer, how easily the product can be configured to match the customer requirements and how customisation can be done for a specific customer. Create a highly flexible functionality, where each and everything can be configured, it definitely allows businesses to sell easily since it can be adapted to customer environment, but deployment becomes a nightmare. Customer cannot deploy it on their own and highly specialised implementation teams are required to deploy it. This increases the cost of on-boarding a customer. Create a highly inflexible, constrained functionality and businesses cannot sell it easily since every customer’s requirement is different from the other, yet on-boarding and maintenance becomes easy.
Standardised product configuration patterns, standardised functional operation patterns etc can help in the creation of “runtime environments with inherent in-built features to abstract common features” across modules, helping designers and developers to only focus on incremental functionality as opposed to the whole functionality from scratch for each module. This reduces the number of designers and developers working on a specific functional modules driving down the cost of development.
As an example, let’s consider a shipping module that needs to load the shipment into the truck at the dock and a yard management module that needs to check in a truck at the gate. On the face of it, these two seem totally different functionalities and need to be designed separately. Yet, if we look at them closely, we find that both functionalities work with trucks, the trucks need to be recognised by the system and find a way to be created within the system, both need associated shipments with them, whether incoming or outgoing and more can be recognised based on requirements. We find we can put in a functional architecture that define how that system works when “any trucks that needs to be processed by the system”.
So, one of the functional architectures put in place can involve a RFID tagging of the truck. Irrespective of what process need to be run on the truck, the truck is always recognised by the nearest RFID reader reading the truck’s ID from it’s RFID tag. The location of the truck is recognised by which RFID reader has read the tag and an appropriate algorithm to locate the location of the truck. The advantage of such a forced architecture helps when customers require other means of recognising trucks.
The other dimension to the functional architecture is the communication between various functional modules. The event driven architecture is one method of providing a structure to communicate between various modules. Functions are triggered by functional events occurring in the system. The impact of such a design vs a all for themselves find a way to communicate architecture shows itself when customers require a la carte features, where they would like to choose the features they use.
Thus functional architecture impacts the sell-ability of the product and the cost + time for development of the product features. It has a direct impact on the customer sub segment that can be targeted for selling the product and when defined correctly helps expand the customer segment easily without much rework involved.
Development and Deployment Architecture
Typically it is considered that the MVC architecture, microservices architecture and others fall into the development architecture category. Yet, it is not true. MVC is just a design pattern that makes developer life easy and microservices is a deployment architecture and should not be considered as a development architecture. The problem solved by the microservices is related to deployment viz-a-viz loose coupling for heterogeneous scaling of frequently used services and non-frequently used services. It should be retained to solve that problem as opposed to solving modularisation and functionality isolation.
Typically architecture is only considered to be a necessity of the technology team and only consideration when selecting architecture seems to be to make life easy for developers and designers. But, this should be the last consideration. A good designer or developer can turn any architecture into an asset to achieve any functionality, since they have full control over what is coded. What needs to be considered when putting down architecture are the customers and the business. The problems that need to solved in a development architecture should be related to “easy customisation” for customers, “agility in design and development”, “incremental development”, “homogeneous development” and so on. What this implies for the business is “How fast can the product keep up with the change in market experiments without losing it’s integrity and having to be rewritten?” and “How long can the product take enhancements and bug fixes before it breaks down and has to be redesigned?”
It should be recognised that, irrespective of how mature the market is, product development or enhancements are experiments. The market may or may not accept the features as it is currently coded. Change is the way of life and fast change is an absolute requirement for businesses. Create an architecture that is not agile enough to take modifications on the fly and you will have a mammoth on your hand which is difficult to sell and difficult to modify and every feature addition needs humongous amount of work. Create an architecture that is too agile and you have a network of criss cross communication problems even within the product and over a period of time you end up with a hodgepodge of modules with multiple of them doing the same work becoming detrimental to agile development which was the initial reason for modularisation.
A lego block architecture or a plug and play where multiple functionalities are written with hook-able extension points that can be hooked into multiple other modules at deployment time can be a development architecture. Enabling the hooks to hook into an external service or hook into an internal API call allows the same block to be deployed into a microservice and scaled separately or deployed along with other blocks to scale together based on the requirement.
Again deployment architecture typically only considers the needs of the scalability of the system with the number of customers. Yet, the major consideration of a deployment architecture should have been the cost of hosting and support when compared to the revenue got in by the same product. Sure, microservices architecture allows us to scale loosely coupled components heterogeneously, but at what cost? If it implies that in the initial stages of the product I still need to have a minimum set of hosting sites to even host the product for a demo, then the cost to revenue ratio is skewed. The deployment architecture has to be such that it can scale from just a simple single low-cost machine to horizontal scaling as the number of users of the product increase.
Architectures have a close tie with the business and market targeted by the product. Irrespective of the type of market being addressed (immature, mature), architecture should be dependant on market segment sizing, time to market and cost of hosting and support of a product and can be considered to be a fine balance of all these components as opposed to being a purely technical requirement.
Published on Java Code Geeks with permission by Raji Sankar, partner at our JCG program. See the original article here: Architect for business, not technology Opinions expressed by Java Code Geeks contributors are their own. |
