Table of Contents
Building a program used to look like gambling in a casino three decades ago. Projects used to fail or were over budget, schedule, or missing functionality, and only a minority met initial expectations. The problem was in the way IT projects were planned. Later, the software development scenario took a turn for the better wherein – a team of representatives gathered requirements, development was scheduled and budgeted. Thousands of pages of documentation were handed off to the tech team to design and development. Eventually, the system was integrated into existing processes and tested. This was called a waterfall model as steps were discreet and strictly followed each other.
Today the drawbacks of this approach seem obvious. Planning and documentation can take months but what if you’ve made mistakes and the software solves non-existent problems? This would only be revealed at the end of the cycle and estimating new features that need deep research was essentially guess-work. An additional headache became evident in enterprises and projects: How to translate business requirements to technicians? Project Managers and Analysts that worked on analysis stages spoke a language that was completely different than what the engineers spoke. Programmers use tech puzzles, business problems, which makes the gap between planning and coding deeper. There was a need for someone who would take technology leadership, have a high-level view of the problem, and suggest a solution in a language that is accessible to the technicians.
In 1999, some engineers suggested creating software in short iterations which involved re-evaluating assumptions and results at the end of each development phase. This technique was called the Rational Unified Process. This partly solved the first problem related to the long planning and feedback cycle. (Inception -> Elaboration -> Construction -> Transition)
However, today most development teams use other iterative – Agile Methods like Scrum, Lean, and Kanban. But bridging the gap between requirements and technology helped address the second problem – communication difference. Later this problem was dubbed into Solution Architecture and the role of the person leading it was known as a Solutions Architect.
The term architecture was borrowed from the construction industry to highlight the complexity of problems. These were enterprise systems after-all. The term also depicts advantage points. Architects oversee the big picture without diving into low-level technical details. Today we know three main rules related to architecture: Enterprise Architect, Solutions Architect and Software Architect. First, there were Enterprise Architects and Software Architects. Solutions Architects were not recognized in architecture frameworks that were prevalent in the 1990s. But Solutions Architects’ role emerged as a middle ground in between Software and Enterprise Architects as a patch between a wide enterprise perspective and a narrow tech perspective.
Ultimately the roles differ as to how high their advantage points are:
Gathering Requirements – Any software development starts with gathering requirements from a diverse group of people, stakeholders, user experience specialists, or even end-users. Business Analysts are in charge. The document requirements (functional) in user stories – description of product behaviour from a customer’s perspective. Non-functional requirements include the general qualities of software like speed, maintainability, security and some others. Besides the requirements, any project has its constraints like a set budget, manpower, timeline, licensing, and risks. A business analyst provides all these inputs to a solutions architect. Later is required to convert that input into a higher-level technical guide. But there is an additional level of complexity.
Compatibility With Legacy Systems – Usually a product never exists alone. They must fit into the current enterprise architecture and other systems that the company has been using before. For example, as you use an old legacy monster, your admin panel should be able to tame it and communicate with it. Solutions Architect considers existing enterprise architecture to ensure that a new product fits well into the existing ecosystem.
Choosing Technologies, Strategies, And Patterns – If we look at the Amazon web Services we get the idea of the problem domains that IT solutions Architect handles – Design/Define resilient architectures and performant architectures, specify secure applications and architectures, design cost-optimized architectures, define operationally excellent architectures. An architect building an AWS based system mainly decides which Amazon Cloud Service to use and how do the client’s salespeople upload their sales figures daily. They need a durable storage solution for these documents that also protect against the users accidentally deleting the important documents.
Construction Architects work on concepts and plans. Solution Architects work on diagrams. Unified modelling language (UML) was introduced for visualizing how the software works. This can be used to create very large systems with modules, services, databases, flows or even movies. Now this language is widely used to describe architectures. But this isn’t the only way to describe architecture. With the growth of cloud services, their providers also suggest individual visualization methods. This is how business needs are translated into user stories and then into a format readable by engineers.
Solution Architects are required to create diagrams, reiterate, tweak, and lead the communication with different parties; stakeholders, and project managers to capture and handle the business problem and pitch a solution;
Business analysts are required to work over requirements;
Enterprise architects are required to fit a solution into the corporate ecosystem, engineering team, and architects to break down tech details.
Solutions Architects provide an overall technical vision for a particular solution.
This practice can be managed in-house or can be outsourced as a specific set of services. They are typically involved in creating the designing the application/s, and some services within the organization, which can eventually help development teams. They have a balance of technical and business skills and their focus is to create technical decisions regarding the solution impact the business outcomes. They make the development teams to understand the most complex problems in simple terms and are responsible for the vision that underlines a solution and to bring that vision into practice.
The selection of specific technologies isn’t limited to cloud services only. They are as well involved in the following tasks:
Usually, a Solutions Architect has an engineering background and a pedigree of complex projects. Framing intricate requirements into an architecture takes a complete understanding of the product from the client-side, right through the databases – Operating Systems – Virtualization – Servers – Storage – Networking – Data Centres. Most likely, a solutions architect would understand a domain, the intricacies of financial systems, healthcare software or travel and many more. They may also have tech domains. Cloud providers like Amazon Web Services and Microsoft Azure for architect certifications, to demonstrate their proficiency with these ecosystems. Organizations must look for that if they plan to hire one. And the software skills must also be appended to the list to keep all that communication coming.
The use of solutions architecture helps decrease the budget overrun. This improves customer satisfaction and finds a better technical fit for project results (MongoDB, Angular, Express, NodeJS etc.)
A solutions architect is also known as a solutions designer or a product architect or a product owner. Their overall responsibilities are shuffled between technical and business responsibilities involving design, implementation, and security, communication with clients, checking the network requirements and ensuring the appropriateness of the database architectures. They also need to cover the risks of misalignment of products and checking it with the stakeholder requirements. Their overall purpose pulls the case to ensure that the solution fits the defined purpose.
Despite this, not every project requires a solutions architect. If you create a landing page, or small modules or minor iterative improvements, it is most likely that you won’t need a dedicated Solutions Architecture. As one of the building blocks of enterprise planning, solutions architecture remains in the realm of complex projects. That too probably deserves careful thought. Have a project that requires an expert communicator? Allow us to have our beliefs on your project requirements; contact us now!
Neeti Kotia is a technology journalist who seeks to analyze the advancements and developments in technology that affect our everyday lives. Her articles primarily focus upon the business, social, cultural, and entertainment side of the technology sector.
Or send us an email at: [email protected]
