I’d like to talk about another idea I have for improving system architecture which is growing Solution Architects. I believe that one of the primary value propositions of an architect is to mentor and transfer knowledge from their architecture experience to the less experienced. I’ve observed that self-proclaimed architects tend to pull from their background such as software/hardware/mechanical engineering, business analysis, packaged software implementers/configurators, even project management! Not too surprisingly there is a significant bias to what these individuals feel are required skills for Solution Architect. I’m not all that confident that there is a right and wrong skills set for the generic Solution Architect, but I wonder if there is a set of core skills that an architect should obtain before acquiring the title Solution Architect to mitigate poor solutions as well as confusion from those around him/her.
I admit, what has triggered this entry is a result of trying to quantify what a Solution Architects is as a result of meeting countless imposters and witnessing their countless system design blunders. It appears that there is no accepted, industry-wide standard skill set that a Solution Architect must have and I see this as a need that must be filled…so I’ll invent one. Here is an approach a fellow colleague and I have come up with which I’d like to throw out to see if it might be interesting to the Architect Community.
The Approach: I used to perform skills assessments while a technical consultant to measure an individual’s skills for a particular project. The result of the skills assessment was a gap analysis which I would use to contribute to a Readiness Plan that would be used to ramp up the technical team for a large project. This approach has worked well for me and mitigated poor system design and solution delivery risks early in the project lifecycle. I’ve taken this concept and applied to produce a development plan for those wanting to become a Solution Architect. The high-level process we’ve come up with to date goes something like this:
1. Build Skills List for a Solution Architect
2. Have an experienced Solution Architect assign the maturity an individual would require for each skill such as:
a. Value Description
b. 0 0 Non Existent. This skill does not currently exist.
c. 1 1 Weak. This skill exists but not able to work independently without assistance
d. 2 2 Moderate. Good skills exist but requires periodic assistance.
e. 3 3 Strong. Highly capable, this person is often sought after to assist others.
3. Have an experienced Solution Architect interview a candidate and assign a value based on the same value table above to as accurately as possible determine the candidates ability for each skill in the Skills List
4. Calculate the skills gap for each skill of the candidate
5. Stack rank the sills based on the skills gap in descending order
6. For each skill that requires maturing, have the experienced Solution Architect list prescriptive recommended guidance describing what the candidate should consider for improving that skill
7. Have the candidate then assign a priority for each skill requiring maturing based on skill gap and the estimated effort to mature the skill
8. Build the candidate’s development plan using the guidance from the experienced Solution Architect.
I’ve run this approach past a few colleagues and it seems to be intriguing…at least in theory. I think that the trick is identifying the specific skills and their maturity value. Like I noted above, I don’t know if there is a right or wrong skill set but wonder if the skill set should be maintained by a community of architects. I’ve started such a list based on information from the Microsoft Solution Framework, industry research and my experience. Below is a brief outline of the actual skill assessment document and I are building. We have more on this so if you’re interested please let me know. Also, note that the skills are grouped by MSF team role because we think a Solution Architect must have strong skills in every project team role but is an expert in Solution Architecture.
Roles and Responsibilities
Entity Relationship Diagrams
Object Oriented Design Patterns
Design and Develop for Performance
Design and Develop for Security
Design for SOA
Methodologies and Techniques
Quality Attribute Skills
Business to Technology Strategy
Alignment and Investment Strategy
Business Community Organizational Aspects
Project Management Capabilities
Business Process Analysis
Business Process Execution
Unified Modeling Language
Daily Test Process
Business Process Modeling
Unified Modeling Language
Use Case Diagrams
Business Process Analysis and Design
User Interface Design
I am gathering information to submit a request in 2007 to enter into the Architect program. Your blog is very interesting. Do you recommend other sites/blogs/books where I can obtain information or case study examples/submissions to the program you are talking about?
Little Rock, AR. USA
Hi DZ. The aim of this entry is to share some of my thoughts on the idea of grooming Solution Architects - there is no program as of yet. Microsoft Certified Architect (MCA) is another way to improve Solution Architecture from the aspect of accreditation. I'd like to evolve Solution Architects which might include along the way accreditation of MCA and most likely other certifications offered by Microsoft and other software industry accepted organizations.
Anyway, getting back to your request of resources that I leverage. I thought it'd be great to have Architects share where they go to be current, and have joined IASA to start just this but haven't had much traction to date. Do you think this would be useful? Btw, I once tried this with a couple of other colleagues and found that when I sent them to one of my resources they didn't get it and misinterpreted what that resource had to offer a Solution Architect. I think that just offering a resource isn't enough and this is one of the reasons I propose step 6 in the process in my blog. Regardless, here's a few resources external to Microsoft I use that should provide immediate benefit:
- TheServerSide.Net: http://www.theserverside.net/talks/index.tss
- Design Patterns in C# and VB.NET - Gang of Four: http://www.dofactory.com/Patterns/Patterns.aspx
- Martin Fowler: http://martinfowler.com
- Microsoft patterns & practice: http://msdn.microsoft.com/practices/topics/patterns/
- Enterprise Integration Patterns: http://www.enterpriseintegrationpatterns.com/toc.html
- SEI: http://www.sei.cmu.edu/architecture
- DSM Forum Domain-Specific Modeling: http://www.dsmforum.org/
- IEEE: http://www.computer.org/portal/site/software/
- Architecture Journal: http://architecturejournal.net
- ArchiMate: http://www.telin.nl/projecthome.cfm?id=48&language=en
I came across your post and found it very helpful. Thank you!
One question though, has there been much progression in this area? One of my goals is to acquire the MCA and am looking for references to help.
WRT to the Skills Assessment idea, it hasn't gone as far as I would have liked. At the moment, we have a tool which manages an Architect's skills as described above but due to several pressures (ie re-orgs, lack of central accountability, etc) it hasn't gone much further. The good news is that there are a few like-minded folk now in positions of accountability that are keen to pick this back up and have it driven by our Architect Community within MSFT. This was the vision from the start and I'm happy that this might become a reality this year.
WRT to MCA, there are several references for preparing for it. The Skills Assessment is very useful to the MCA but not intentionally. We just arrived near the same place is all. You are probably already aware of this url but just in case www.microsoft.com/learning/mcp/architect.
Also, I was a part of an interesting project by the IASA called the Skills Library. I wrote the article "Implementing System Quality Attributes". Here's a blog entry on this http://blogs.msdn.com/gabriel_morgan/archive/2007/03/20/implementing-system-quality-attributes.aspx. The Skills Library initiative is another interesting approach at describing the skills necessary for Solution Architects that may eventuate into certification someday. For now, it's worth having a look at to help describe/outline skills sets of a Solution Architect.
I'll ping a colleague of mine close to the action of MCA and get back to you if there's more to share. Stay tuned.
Thanks Gabriel! I recently joined IASA and find it being helpful in my learning. The links you provided have also been very helpful with a project I'm leading right now.
This is a great idea as a personal development tool, although there are pitflls to it. What if your checklist becomes the foundation of a BOK? Then you're in trouble :)
Thanks for such a great help from you people.
I am aspiring to be a S.A and this really helped me a lot.
Welcome to the July 1, 2008 edition of Carnival of Enterprise Architecture (Issue #10). Business Process Management Stephan Grindley presents Enterprise Asset Management Software - a Great Way to Manage posted at Asset Management Articles. Bozidar Spirovski
I strongly believe that Leadership is a critical competency for successful Enterprise Solution Architects
Great..insightful article. Thanks for sharing this info post.
Gabriel, almost six years on from the original post do you still believe those skillsets hold true? I'm currently an Enterprise Architect that may have to take in Solutions Architecture too in the future. I thought SA was also more about being in touch with a greater level of detail than an EA. What do you think?
There’re are lots of opinions out there on what does a Solution Architect (SA) do versus other architecture disciplines or any other disciplines like Product Manager, Program Manager, Developer and in a company for that matter. The skill set list I provided in the blog could probably use some refinement but not much to make that much of a difference. In my opinion, the Solution Architect role is a project-scoped role. Within an Enterprise Architecture team, it’s popular these days to have an Enterprise Solution Architect (ESA) role. The two are similar and different. They are similar in that they are both accountable for leveraging all related domains (business, information, technology, etc) to design something. What’s different is the output and the intent of the output. SAs design solutions to project-scoped business problems with specific measures of success and the ESAs design high-level, directional system models and define technology usage policies to help project teams align to.
I’d like to add something here. I don’t think that every org should have a standard set of roles that are copy’n pasted from some industry team model. Each company and organization within a company will have a very different situation than another. For example, one company may be in the throes of economic turmoil and require scaling down the infrastructure to reduce costs. In this situation, an EA team may not need to have a dedicated title of “Information Architect” or “Solution Architect” but rather have Infrastructure Architect to focus on scaling down the infrastructure. Of course, they’ll likely need a dash of Information Architecture and Solution Architecture skills to build out the related artifacts to get the infrastructure task completed. I suppose I’m just highlighting to you not to fall into the trap of assuming each named architecture skill or discipline requires a dedicated architect title in an arch team.
I like the approach of first understanding the major business problems, then dedicating the right arch roles necessary and enable them with just enough arch domain disciplines to get their job done. For example, I’m in a situation right now where the business I’m in requires the need for tighter project portfolio management to enable their business strategy. So, we’re strengthening our Business Architecture skills with titled Business Architects with a tad of Information Architecture and Solution Architecture. Of course, I always assume that the titled architects have project delivery experience, a strong appreciation and experience in all traditional arch domains.