Why do we need Solution Archtects?

Why do we need Solution Archtects?
Submitted by Andrew Winterburn on 02 Apr 2009

Problem statement
Only 29% of software projects in large enterprises produced acceptable results that were close to agreed time and budget) . 53% were significantly over budget and schedule, and 18% did not deliver any usable result. The projects outside the 29% have an average budget overrun of 56%. (Standish, 2004) View image
Two big trends that have tremendous impact on enterprise grade solution development are:
o Globalization of software development
In ideal project people work close to each other and have an agreed upon way of working, any problems are quickly solved through personal contact. Through shared project experiences in the past there are is common understanding of the way the work is done. Once distributed development starts all the interpersonal alignment mechanisms of the ideal projects are effectively negated. (Herbsleb, 2007)
o Exponential increase in software complexity due to service orientation.
For every 25% increase of complexity in the business domain there is an increase of 100% in the software complexity for the systems that need to support that business. Because of the trend of service orientation there is much richer interdependency between business and especially in the software that now automates these interdepencies. If you plot it in a diagram it is clear that software complexity increases exponentially where business complexity increases lineairly. (Glass, 2002) (IfM and IBM, 2008)

Generally speaking the world is not good at doing IT projects and we are upping the ante by vastly increasing the complexity of the systems that need to support new business eco-systems!
A little segway into system oriented design
One of the major roadblocks on the way that leads to delivery success are the trenches between the professionals of different disciplines. In that respect the IT industry can learn a lot from the system oriented approach that was adapted by successful high-tech companies. These companies adopted wholistic R&D processes around integration teams instead of the stovepiped waterfall oriented approaches that they used earlier
This holistic approach is called system oriented as they look at the system as a whole instead of a bunch of products. The team needed to have a “T-Shaped” combination of skills. T-Shaped will be discussed later in this article.
By doing this they reduced time to market with 25% and development costs with 50%. Given the number of large programs that do R&D sort of activities by leveraging new technologies for business opportunities it is in our opinion worthwhile to apply this approach to large transformation and IT programs. (Iansiti, 1993)
What is the width of the solution delivery field?
In order to deliver solutions, within time and budget, that provide business value three different domains need to align. Traditionally these domains have evolved separately into different disciplines with separate methods, tools, knowledge and, more important separate roles in projects:
o Understanding of the Business Needs & Problems
The typical domain of Business Analysis: The set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change. (IIBA, 2006)
o The application of engineering on the IT Solution
The typical domain of System Engineering: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (IEEE, 2004)
o And last but not least, the management of solution delivery
The typical domain of Project Management: the discipline of planning, organizing and managing resources to bring about the successful completion of specific project goals and objectives. (PMI, 2008)
In order to get a solution out within budget and time all these knowledge areas need to be successfully applied in an integrated fashion. Because of the reasons described earlier, the separation of domains within solution delivery and therefore the non-holistic way in which projects are governed has become an ever increasing hurdle for successful solution delivery. This issue is one the main driving factors in the rise of the solution architect, who is positioned as a major player in project governance.
Enter the solution architect
While project managers remain the primary role for managing solution delivery, architects will play an increasing role in leading projects – like construction architects, who remain at the side of the project leaders until completion of the building – ensuring quality, usability and time to market. This, holistic looking, role we call the solution architect.
The solution architect takes architectural, quality and feasibility responsibility for a given domain or system, integrating the views and capabilities of various groups of specialists.. It is the roles objective to make sure a solution is delivered that is acceptable for all the stakeholders. (it should leave them just not unhappy ;-)
In order to do this successfully, and form a well-balanced team with the project manager the solution architect should have a leading role on the Business Analysis domain and System Engineering, making sure that requirements, design and construction stay aligned and are feasible. Additionally he should have a supporting role in the project management domain, making sure that planning, resources, commitments and risk recognition stay in line with the solution under construction.
For a typical IT project his span of control will have to span across a great number of knowledge areas in order to be able to take responsibility for the solution’s architecture, quality and feasibility.
The solution architect is leading in:
o Enterprise Analysis, Requirements Elicitation, Requirements analysis & documentation , Solution Assessment & Validation (IIBA, 2006)
o Requirements, Design, Construction, Quality (IEEE, 2004)
While he’s supporting in:
o Requirements planning & Management, Requirements Communication (IIBA, 2006)
o Testing, Maintenance, Configuration management, Engineering Management, Engineering Process, Tools & Methods (IEEE, 2004)
o Project Integration Management, Scope Management, Time Management, Cost Management, Quality Management, Human Resource Management, Communications Management, Risk Management, and Procurement Management (PMI, 2008)
The solution architect major deliverable is the integration of all delivery aspects during all phases of solution delivery. He is constantly striving for this integration taking actions in areas where he leads, initiating actions and decisions in areas where he’s supporting. The solution architecture is no longer the major deliverable. It has become his major tool for integration, as well as for recognizing potential misalignments.
This role is sometimes called systems architect but we think it does injustice to the fact this holistic architect is deeply involved in both business, management and technology.
Who can be a solution architect?
The following pictures describe the context of a solution for administrative systems. Within this context you see an example for a solution architect with a custom software background and who has developed a breadth of understanding across all the domains the need to be aligned for project success. The deep knowledge of custom software is the vertical bar of the “T”, the wide knowledge across the domains is the horizontal bar of the “T”. Hence he/she has become a “T-Shaped” professional.

Coming from undergraduate or graduate level a professional needs years of maturing to understand there is more to reality than just their current role or discipline. The nice thing though, there is no perfect discipline from which a solution architect should come. Any discipline like engagement management, packages, business analysis, custom software, infrastructure is fine.
What should be a personal driver behind this is an authentic interest in the other people and their disciplines and the willingness and ability to align very different individuals whose world is sometimes very small compared to the real problems at hand.
Anton van Weel & Wiebe Wiersema
Bibliography
Glass, R.L. (2002) Sorting Out Software Complexity. communications of the ACM, 45(11), pp. 19-21.
Herbsleb, J.D. (2007) The future of Socio-technical Coordination. In Future of Software Engineering FOSE'07. IEEE.
Iansiti, M. (1993) Real-World R&D: jumping the Product Generation Gap. Harvard Business Review, May-June, pp. 139-47.
IEEE (2004) Software Engineering Body of Knowledge. IEEE
IfM and IBM (2008) Succeeding through service innovation: A service perspective for education, research, business and government. Cambridge, United Kingdom: University of Cambridge Institute for Manufacturing.
IIBA (2006) Business Analysis Body of Knowledge. International Institute of Business Analysis
PMI (2008) Project Management Body of Knowledge. Project Management Institute
Standish Group (2004) CHAOS Report.Standish Group.