To build a successful solution architecture practice you must first understand the appropriate role and capabilities of a solution architect. We interview many organizations regularly about their current roles and the most common form of solution architecture is related to delivery of projects (of a certain size or higher). Although the vast majority of the individual architects come from a software background that is not always the case. In fact we are seeing more and more solution architects come from business or one of the other specializations. This aspect, base skill matching, is the single most important aspect of assigning a solution architect in the success of the project. What most sophisticated organizations do is assign solution architects based on skill, solution type and architectural difficulty.
For any type of architect to create a winning and balanced solution is to effectively navigate the constraints in the projects. In the new Iasa Solution Architecture course we have developed a tradeoff analysis pattern that aids in delivery of a balanced and effective solution. Within a solution space there are 4 primary influencing elements that need to be balanced. The most successful architectures find tradeoffs that deliver value in each category but balance them against other categories and constraints. When beginning a project we teach our solution architects to create a series of ‘management’ tools which will aid them in delivery. These include balanced scorecards, architectural analysis tools, and value management tools in addition to the standard viewpoints and stakeholder management tools in use today.
In the following solution management tool the architect creates a set of tradeoffs balancing the local influences, project and technology, against the global influences, enterprise and stakeholder. This helps the architect find the best fit for the delivery of the solution.
Enterprise Perspective: Enterprise level influences come from decisions made that affect the entire organization. For example, technology standards and constraints play a large role in enterprise architectural guidance, yet often these are not accounted for until late in the solution lifecycle. In addition, the solution architect must be aware of the current business model, the target business goals for the year, the competitive landscape, the latest trends in the industry and the other solutions being delivered in the enterprise. Creating a list of these influences should be one of the first steps a solution architect makes when entering the company so that it need only be updated at the beginning of a projects. If the organization has enterprise architects it is essential that you build a strong relationship with them to ensure the EA perspective is appropriately represented in your final architecture.
Stakeholder Perspective: The stakeholder perspective includes any individuals who are interested in the outcome of your project. In our Core course we teach the use of the Stakeholder Analysis from Mind Tools. However, as an architect your relationship with stakeholders goes far beyond the project and it is essential that you understand the primary drivers and difficulties with each group and the important individuals within them. Effective stakeholder management includes many aspects such as their technology capability and understanding, their requirements for the project, but the single most misunderstood and utilized element is their business goals. Find out how your stakeholders are incented in their jobs and use that as your primary driver and you will be successful. For example, if the Sales VP is one of your primary stakeholders, finding out this quarters targets will drastically increase the quality of your communication and may influence the end state of your architecture.
Technology Value: One of the localized (I use this to refer to the proximity of a technology solution decision) and easiest to control elements of your architecture is the technology components that are built, bought or used. In fact, most would argue this is the single most important element of a solution architects role. However, successful architects balance these decisions with the other tradeoffs that must be made. In any case, it should always the solution architect that makes final tradeoff decisions between components. However, most architects use only requirements and constraints as their guiding decision making criteria. The very few architects that use value measurement within their design criteria are the most successful in the world. For example, the requirements of a solution might require the use of a small amount information from another system in the enterprise. The cheapest alternative would be a file transfer or database level integration. However, because of your enterprise level awareness you also know that a service hub is being setup and that a number of other applications will need this data as well in upcoming projects. If you are able to manage to value you may be able to build in tradeoffs that allow this hub to be used instead of the cheaper but more fragile integration technique. Demonstrating these tradeoffs using a common value management approach (showing the value in numbers) will massively impact your personal success and the success of your final solution.
Project: Project influences are often cited first in blogs and articles because in IT the world revolves around measurements of time, budget and requirements. However, for an architect these are only one set of influences, and often the least important ones at that. Think of it this way. If the marketing team got an advertisment in on time, on budget and meeting requirements but it failed to generate any interest in your product or services, would you consider it successful? The architect must account for these measures, if nothing else than our stakeholders do, but they must be balanced against the other areas of importance.
However your organization goes about solution architecture and whatever your current level of skill it is essential that you account for these influences in your final architecture.
Find out more about our Solution Architecture Course.
Related articles
- Solution Architecture – What is it all about? (softpathtechnologyblogs.wordpress.com)
- Building an Architecture Steering Committee (iasaglobal.org)
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCwQFjAA&url=http%3A%2F%2Fwww.mindtools.com%2Fpages%2Farticle%2FnewPPM_07.htm&ei=R40TUoHKNaW02wXyvIHQBQ&usg=AFQjCNE4bgZdwTXxtiBUlEytTW9sayTLRA&bvm=bv.50952593,d.b2I
