There are always debates about the definitions we use. There will always be debates and that is a good thing. However, nothing I have seen in the past 12 years leading Iasa has been as contentious as two terms; enterprise and solution architecture. First I want to lay out the Iasa definition for solution architecture and it’s basic relationship to both specialized architecture (software, infrastructure, etc) as well as enterprise architecture.

Sign up now for Iasa Solution Architecture Courses and Certifications – Seattle, Nov 4th and Sydney, Nov 25 – Instructor, Paul Preiss, CEO Iasa

The industry is split into two camps on solution architecture as a role – the generalists and the specialists.This relates both to the background of the practitioner and their target career path. The ‘generalists’ have a smaller chance of being from a deep technical background. They are generally targeting a long term career in Enterprise Architecture or even IT Management. The specialist role often comes from a depth background in software, infrastructure or information architecture. They are generally not looking to move out of their current depth area and are in fact looking to go deeper into their area. The place where most organizations have difficulty is when to assign a generalist and when a specialist to the role and to make these assignments and career trajectories more formal. For example, I worked on a 120 million dollar retail project that was primarily based in software. While a generalist may have been able to handle it, it was very intensive in the areas of software design and development. This is one of those areas where a full professional specialist is called for. One of the other projects I worked on broke out evenly in challenges across business, information, infrastructure and software. Obviously in that case a generalist is called for. While developing your engagement model as a team you should follow these steps to assign the right architects to the right projects:

  1. Get access to the project prioritization process – even if you dont have a seat at the table you should know what’s coming up next
  2. Review each project business case for architectural complexity and skill requirements
  3. Assign priorities to each up coming project in terms of business value (based on business case and complexity)
  4. Review these as a team and recommend appropriate architects based on skills needed, complexity and priority
  5. Review progress as a team and utilize a mentoring program to help cross-pollinate skills and experience
  6. Rinse and repeat.

Based on the Iasa model we treat the solution architect role as a delivery architect. The best solution architecture balances, team dynamics, business priority, enterprise constraints and technical considerations. The goal is to deliver the best solution in terms of competitive advantage (not just on time and on budget). This allows the group to be responsible for the overall design but the architect to own the value contribution of technology. The architecture represents the set of significant technical design decisions and is most commonly associated with the project manager and technical lead roles.
I’m thrilled to be teaching this course next week in Seattle and in November in Australia. Hopefully I will see you there!