Nice presentation. I’ve just started my solution architect journey and I’d love to run through the architect engagement integration map for my organisation. Could you share a digital copy of the slide?
It is good to see the role recognized; and the slide show is good also. At a meeting in London about a decade ago (having already been teaching to the BCS professional certificates in enterprise and solution architecture for a couple of years) I asked Paul what IASA said about the solution architect role. So, as you might expect from that history, I do have some comments on the slide show.
-1- It leans towards technical more than business architecture. As we teach it, solution architects must start with the business context, working with business analysts (not business architects) as need be to understand the roles and processes in the business activity system, and the data created and used. (The “solution” is not necessarily application development or deployment.)
-2- It seems to me a tad over the top, giving the impression of a super hero – a know all and do all. Often, broad experience counts more than deep experience, since the solution architect has to join up a variety of specialists, ranging from business analysts, through DBAs and security architects, to software architects and infrastructure (devices, networks, cloud) specialists. All such specialists may contribute towards the solution outline or architecture definition.
-3- I’d emphasize that the solution architect should
• be accountable for a solution meeting non-functional requirements
• understand a variety of alternative design patterns and make trade-offs between them (regardless of fashion).
• relate to both project managers and enterprise architects, who can pull in different directions.
(I join solution architecture to enterprise architecture in a value stream here https://www.linkedin.com/pulse/value-stream-architects-graham-berrisford/)
Hi Paul,
Nice presentation. I’ve just started my solution architect journey and I’d love to run through the architect engagement integration map for my organisation. Could you share a digital copy of the slide?
Thanks
Joe
It is good to see the role recognized; and the slide show is good also. At a meeting in London about a decade ago (having already been teaching to the BCS professional certificates in enterprise and solution architecture for a couple of years) I asked Paul what IASA said about the solution architect role. So, as you might expect from that history, I do have some comments on the slide show.
-1- It leans towards technical more than business architecture. As we teach it, solution architects must start with the business context, working with business analysts (not business architects) as need be to understand the roles and processes in the business activity system, and the data created and used. (The “solution” is not necessarily application development or deployment.)
-2- It seems to me a tad over the top, giving the impression of a super hero – a know all and do all. Often, broad experience counts more than deep experience, since the solution architect has to join up a variety of specialists, ranging from business analysts, through DBAs and security architects, to software architects and infrastructure (devices, networks, cloud) specialists. All such specialists may contribute towards the solution outline or architecture definition.
-3- I’d emphasize that the solution architect should
• be accountable for a solution meeting non-functional requirements
• understand a variety of alternative design patterns and make trade-offs between them (regardless of fashion).
• relate to both project managers and enterprise architects, who can pull in different directions.
(I join solution architecture to enterprise architecture in a value stream here https://www.linkedin.com/pulse/value-stream-architects-graham-berrisford/)