At the next MSDN Live tour in Norway (in April), I’m doing a talk about Solution Architect and SharePoint 2010 for Developers.
I would like to air some ideas I have for the Solution Architecture talk and hopefully get some feedback, perhaps some tips and hints that can improve my talk.
What’s in a name?
There is no way I’m going to even start to try defining the name architecture or the architect role. It is something different to every single individual, in the same way as I’m never going to define what a developer truly is.
Though we can talk about distinctions between what it means to be a developer and what the role of an architect in comparison could potentially be.
Architecture is primarily about the bigger view of things and the spider web of interactions between humans and systems in an organization and across organizations. There are many forms of architects, from functional architects, enterprise architects, software architects and what I’m going to talk about: solution architects and architecture.
Architect? You make diagrams, right?
Well sure, architects often use tools to draw their ideas and conclusions, even if it’s just on pen and paper. Source code is the primary language for a developer and diagrams is the primary language of an architect. More than that, I’m not going to talk about diagrams. Other than say, they are a good tool for communicating intents, ideas, thoughts and meaning. Architecture is not about diagrams, it’s about everything else.
The Solution Architect Role
When I talk about the solution architect role, think about the role from a technical perspective, not a functional one. Here is a diagram that tries to illustrate some of the interactions that the architect has with other roles in a project.
Depending on the scale and form of a project, the architect is often involved early in the process – and hopefully part of the project until the final delivery date. Unfortunately the identity of the architect have been put on some negative weight. Some people see the architect as someone distant from the project, someone that makes decisions that developers feel the pain from. And this can be true for some projects, and that is a bad position to be in, both for the developers and the success risk of the project.
It’s important that the solution architect is closely involved with the project all the way. Initially they work with the client to gather all the requirements, depending on what type of architect and his or hers responsibilities, they might be both functional and non-functional requirements. Initially often with project leaders and members on the client side and often the upper-management often has a stake in the project and unfortunately sometimes do technical decisions ahead of involvement of others, often after reading an report by Gartner… So often the architect and developers have to work with pre-existing decisions, most of the time, this works out fine though.
The green person in the illustration is the clients network and system administrator, who often have requirements and demands regarding security and deployment. If you’re lucky to be on a project with a designer, the typical black-suite guy using a Mac, they often have insane demands on the interface. I say this with a sense of humor, as usability experts and designers are very important individuals for the success of a project.
Then you have all the others, which are different individuals from inside and outside the organization. Computer security experts might be utilized to do reviews of the architecture and eventually the complete solution.
Users of the final solution is very important, it’s for those we do what we do. If we can’t satisfy them, then there is little point in going forward with a solution.
After a project has been planned, contracts have been agreed upon and signed, the project starts with the project team. Depending on the size, the project team could include advisers, project leaders, developers and others.
The architect often have interactions with all of these roles in a project and their focus and responsibility is often the quality of the overall delivery. Architects are not the individuals who manages the projects and it’s resources, which is a whole different and challenging arena, which luckily as an solution architect, you normally avoid directly. Though it’s a constant battle to ensure the developers get the time, knowledge and tools they need to ensure the quality of a delivery, which is not compatibility with the goal of a project leader who first and foremost want to deliver on time.
Topics for the talk
These are some of my other potential topics on the agenda for my talk, there are so much to talk about on the subject of solution architecture, though I have only an hour and I’m interested in finding the topics that gives most value for my audience.
Topics: Security, Infrastructure, Products or Custom, Cloud Computing, Frameworks, Scalability, Tools, Why you should care about architecture, Become an solution architect.
What do you want to hear about?
Come to MSDN Live!
If you haven’t signed up for MSDN Live yet, it’s about time! The tour starts with Stavanger the 16th of April and ends 26th of April in Oslo.
I work as a senior solutions architect at Steria, who’s one of the partners for MSDN Live. Check out our stand at MSDN Live!