In some companies the term architecture is somehow misunderstood or undervalued. The business and product management might see it as a pure technical thing to structure the software and IT realization of the value offer and cannot see the business relevance right away. On the other hand the software engineering and IT see it as an additional burden about things which seem quite abstract and out of scope.
So, what is the value of Architecture?
In the company there are people, the business and the IT/software. Those areas are all very important for the realization of value for the company and finally for the success of the company.
The people are grouped in teams, departments and support units and this forms a structure in an org chart. The business brings value to the customers and needs a fundamental understanding of the processes, business objects and actors which all together form a model, a structure. The software and IT realizes this offer basically by implementing the structure. The important part is that all those three structures need to be in line with each other and not work against. The more they align the more efficient the organization works.
So whether you see an importance of architecture or not you have architecture in form of those different structures. The value of purposeful architectural work is to align those worlds.
Conway’s law tells: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” (Melvin E. Conway, 1967) So if you need your software solution in a specific structure you need to adapt the organization. This specific structure of your solution is not just a standard IT solution with a state-of-the-art standard architecture. It needs to be fit for your purpose for your business cases and your customers processes. This means understanding the business and speaking the same language is essential for defining the structure of the software solution.
Finally the value of architecture and the architect whether you name him/her that way or not is to connect those worlds, to create a common language, understanding and model and to mitigate. Gregor Hohpe calls this the architect elevator to underline the different abstraction levels, contexts, organization levels and domains and to bring them together.
How seamless are your business, IT/software engineering and people are connected in your organization? What are the main problems you see?