A buzz word that is more than often heard in the IT industry over a decade now is – Solution Architecture. What is it all about? Is it the same as Application Architecture or different? Does Solution Architecture demand different set of skills from Application Architecture or System Architecture?
A simple answer could be – Solution Architecture mostly deals with engineering and re-engineering problems and involves factors beyond lines of code or reusable classes and modules. It is a disciplined approach which considers not just the technical outcomes but also the investments that are in place and the smooth transformation from existing processes and solutions to newer ones while ensuring business continuity.
Most of the Business Process Re-Engineering or Application Integration/SOA based solutions demand for Solution Architecture than a typical Application Architecture. But it is worthwhile to understand it’s not replacing one with another or travelling in different directions.
A very good characteristic of a Solution Architect is to wear a CIO hat while understanding the requirements and constraints of the existing solution and to draw boundaries within which he can develop a new solution.
So, what are those characteristics and what are those boundaries?
– It is knowing the difference between ideal and practical solutions and understanding what works best in that given circumstance.
– It is running the show with the existing Legacy systems, though you personally hate the way they work and the not-so-nice interfaces that they offer to integrate with your solution. Yes, as an Architect you may be tempted to use the state-of-the-art technology or tool that would replace the Legacy System but the CIO inside you should tell which is more profitable for you – replacing or retaining?
– It is planning a gradual transformation of solution to a newer form without disrupting the business that is already running on it.
– It is balancing the expectations of different stakeholders in ensuring what works and clarifying what doesn’t work and why.
– It is organizing around outcomes and not tasks.
– It is differentiating between Perceptions and Reality.
Further, Solution Architecture is leading a team of developers who along with other business stakeholders create a solution. It involves understanding the requirements of the business “as-is” and the concerns of the technical team (including yourself) in meeting those “as-is” requirements. It involves negotiating and making reasonable trade-offs between the Business and Technical groups while keeping the objectives of the desired solution “intact”. It calls for envisioning a solution and bringing all the stakeholders on a common page to take it to implementation and successful completion.
To conclude, Solution Architecture is about:
-Knowing the difference between ‘what can be done?’ and ‘what needs to be done’?
– Developing a Solution keeping in mind as to how yesterday’s investments can be leveraged to continue today’s business while envisioning tomorrow’s business challenges and business agility.