Software architecture definition brokensystems

When software architects are requested to define Software Architecture, we tend to get wide variety of responses. Most of the architects derive their interpretation from one of the dictionary definitions that was probably created in last century. Are those definitions still valid or might require a new 21st century upgrade? Let us find out!

“ Software architecture is the defining and structuring of a solution that meets technical and operational requirements. Software architecture optimizes attributes involving a series of decisions, such as security, performance and manageability. These decisions ultimately impact application quality, maintenance, performance and overall success.”

From my experience the above definition might be obsolete and could be done away with.

In the modern environment with ever shrinking budgets, squeezing turnaround times, and increasing client expectations, driven by the marketing led clamor created by technology evangelists, perhaps a new definition is required that can address the “process” of software architecture in the new world?

The use of word “process” was deliberate as we may want to question one of the foundation stones of the proverbial architecture ivory tower that most of the times considers architecture as a “stage” in software development. Architecture might have a starting point but in modern agile based approach it does not have an end point, definitely not when the development is continuing and surely not when the software development finishes. In any successful software development environment, architecture is always evolving and always morphing into something that attempts to produce better quality within the triple constraints of requirements, cost and time.

As soon as the development finishes, architecture evolution move towards to the next stage which might result in variety of maintenance or continuous improvement cycles, until the solution is no longer fit for purpose. Subsequently when a newer solution get designed, part of existing solution, depending on situation, may get salvaged and reused. In any case the newer solution will generally follow similar evolution pattern and hence architecture as a “process” continues

Architects are never cheap, well the good ones anyways. Hence most successful organisations invest quite a bit on architecture function as they would have reaped the benefits the last time around. Like any other business investment, the primary purpose of investment in architecture should also follow the same principle: “Produce maximum measurable benefit with minimum possible cost”. This means that architecture should be generating benefit for the business and if we go strictly commercial, the benefit or value being produced should far exceed the investment being made. Frankly if architects get only this right, the battle is almost one.

Let us delve slightly deeper in the last one “reducing wastage”. In software development, wastage is a big factor, this can arise when the solution goes through one or more development iterations and some or, God forbid, all of it is found to be unfit for the purpose and then it needs to be redeveloped. This generally happens with one or more of the following reasons

Since so work has been carried out in this space in last few decades, we would have assumed that this is least of worries with clearly defined templates and well-oiled processes to carry out the above tasks. But unfortunately, this is not the case! There is a distinct lack of standards that can be followed easily and which can be made applicable to majority of situations.

Solution should be “simple” as in simpler and clearer communications between various people in a language that can be understood by all concerned parties thus reducing chances of misunderstanding. Architects are often guilty of communicating in way that is difficult to comprehend by various parties. E.g. UML class diagram for a meeting where the solution is being presented to sales team!

So if we summarise above section on reducing wastage, we can probably say that architects should ensure a robust communication process is established where each stakeholder is being provided information in a format that is acceptable to them. And as a supplement, they should also request information in a way that is clear for the purpose of proposing solutions

“Software Architecture is a process that continuously generates additional and measurable benefits for the business by accepting, often evolving, wish lists of the business sponsors as clear requirements and generating solutions to meet those requirements. The architecture solution so produced should be of acceptable quality with minimum wastage and within available cost and time restrictions using communication tools that is suitable to all concerned parties.”

If you see above, we have not mentioned, any of the buzzwords like security, performance, re-usability, modular, component, services etc. that used to be there in traditional definitions. Why? Because in contemporary environment, these should be compassed as part of requirements anyways and having a lower but acceptable quality solution that can be developed in very short time as a MVP is increasingly acceptable to pragmatic businesses.