A few years ago I worked for a company that just created a new IT team for "integration." One member of the team was the "solution architect." There was no formal definition of that role but there was an informal understanding that the person will be responsible to ensure that the system works end-to-end. Since then, the role has become more common and there are more or less formal definitions many of which are very generic and, as a result, they loose any practical meaning. Recently, having the task of training people for the Solution Architect role, I tried again to explain what Solution Architects do and how they do it.

What Solution Architects do:

• Develop the architecture for solutions in one of the following architecture domains: business, application, integration, data, and technology
• Lead or assist the development teams in the implementation of business and system designs which meet the stakeholders’ needs and provide a platform for future enhancements and easy change
• Generate and maintain functional roadmaps across projects to ensure efficiency and re-use across development teams
• Collaborate with the business representatives to understand the business strategies and operations
• Research and collaborate with third-party vendors to develop innovative solutions for complex problems
• Contribute to, document and communicate the enterprise architecture and architecture best practices
• Facilitate the implementation and evolution of a strong software development process
• Mentor application teams in the principles of enterprise architecture

And here is the outline of a course about how to do it:

• Solution Architecture Role in Integration Projects:
  • Integration Projects in the context of SDLC;
  • Architecture Domains, Architecture Deliverables
• Business Requirements for Solution Architects
  • Modeling techniques for Business Requirements: BPMN, UML Activity Diagrams;
  • Use Cases vs Features
  • Non-functional requirements: performance, deployment, security, reporting, operations;
• System Design:
  • Views: System, Process, Deployment, Data
  • UML notation for System Design
  • Typical of integration projects : data sync, order fulfillment, aggregated data view;
  • Solution Design Patterns
• Component Detailed Design:
  • UML for Component Detailed Design;
  • Enabling applications for integration: (XML) Events and Services
• Testing and Development:
  • Why is testing hard?
  • Testing levels: unit, component, system, UAT
  • Role of Solution Architects in Test Plans, Test Cases, Deployment Plan
  • Challenges: multiple versions, security
• Operations, Support and Training
  • Integration solution monitoring;
  • Tools for support: system level logging, log aggregators, dashboards;
  • Integration solutions support in a multi-tier incident management process.

For more information Contact Us.