The Information Technology (IT) inventory of HR role and position labels is broad and deep. IT position descriptions may be closely associated with actual black box technology (like “Microsft Windows Server 2008 Administrator” or “Storage Area Network (SAN) Engineer”), or they may describe roles in a methodology-driven context required for IT success (“IT Project Manager”, “Functional Requirements Specialist”). No IT job label is more loosely defined than the “Architect”, even with a long string of descriptive adjectives (“Component Services Integration Application Architect”).
Taking the “Security Architect” role for example, this person usually does, as well-understood, develop models and abstracted designs (for easier communication) to help build and deliver IT security requirements through engineering methods, constraints, tools and investments. However, does this “Architect” create detailed designs and configurations for security tools? Does this Architect map out and define the security team org structure and responsibilities, both during the build and thereafter sustained operations? Does this Architect take into account (and perhaps influence) security-related money being spent or projects being implemented elsewhere among stakeholders and policy-makers, to help justify or align security design? Does the security architecture include access control designs and processes for the facility, that the IT system or team is housed within?
A more and more common answer over the last 7 years in the world of Enterprise IT Systems Acquisition, Engineering and Operations is that a “Solution Architect” (SA) is the advertised role required to discover, shape and apply relevant, comprehensive contextual awareness during the early phases of an IT-driven program (whether pre or post-award).
This “awareness” is the knowledge container (expressed in consumable plans, financials, models and illustrations) that directly influences how discipline-focused architects and engineers (like the “Security Architect”) achieve the right balance of scope, risk, and resources necessary to deliver an intended contribution to the overall IT system. This contextual awareness also shapes the IT program from the perspectives of investment management, project management, services management and enterprise architecture – a large IT program simply can’t satisfy its direct stakeholders without contemplating its business relationship with all other (or “collateral”) stakeholders.
So, a Solution Architect may be first an enterprise services relationship manager, second a business investment and planning manager, and third a “system-of-systems” architect/engineer (with practical knowledge of the IT context involved) – whose output is shared with and consumed by others as their more discrete focus requires. I’d say the SA is in effect the CIO/CTO of the particular IT investment. John Critchley’s article “A Rough Guide to Solution Architecture” sums it up nicely (paraphrased) – “A Solution Architect helps bridge the design gap between business needs and what information technology has to offer”.
With such a broad scope of skills, knowledge and responsibility – surely there are professional certifications available to establish, build and prove distinct competency in this role – like the PMP, ITIL-Certification, MSCE, etc. More to the point of this article, how exactly does one become (or develop) a “Solution Architect” as expected and understood by those ready to hire (or promote)?
Having been a Solution Architect (as hired) supporting many large systems integrators and their clients (including Accenture, IBM, Deloitte, CSC), and delivering to this expectation according to many similar “role descriptions” – I’m certain there’s no truly comprehensive and singularly warranted Solution Architect certification available to the public. There are industry “Architect”, “Enterprise Architect”, “Solution Architect” (focusing on a specific vendor solution, like Microsoft, NetApp etc.) and “System Architect” certifications available (i.e. from ITAC, IASA, the Open Group, etc.), but no certifications that truly marry the knowledge and responsibility for investing in and catalyzing (i.e. actually getting it started) a capability, with actually designing and delivering it. In other words, pairing the financial and mission responsibility with the technical. (Not that I’ve seen yet – please correct as necessary).
This isn’t to say that any of these significant certifications of expertise in complex architectures isn’t enough for many advertised Solution Architecture roles – it’s simply to say that the certifications themselves don’t carry the weight of real world experience, where people and money matter as much as a good technology design.
The larger companies (i.e. IBM, Microsoft, Oracle, Accenture, Deloitte, CSC, etc.) are internally building and measuring competency in this sort of role with respect to their own methods and assets, their own clients and service relationships – while the smaller companies hire-to-need or press their most senior system or component architects into service with (hopefully) symbiotic collaboration from the program manager, the functional lead, the governance and investment stakeholders. For smaller companies (and low-margin projects), the Solution Architect is usually either someone who parachutes in briefly, or someone who needs a whole lot of help – either way extremely costly and with little enterprise ROI. (Note to small companies – invest and develop within, don’t contract this out).
In most cases, there are really only two ways to first “become” a Solution Architect, and actually to get paid for the contextual advisory role I’ve described above. Either you’re (A) recommended for the role (or a development program) by a forward-thinking and hopeful senior executive (i.e. your benefactor or mentor), or (B) you self-describe and promote yourself as such, land the lucky role and prove it sticks.
Either of these methods presupposes you’ve spent at least a few years learning, becoming responsible for and delivering positive outcomes across ALL of the following IT business and technical disciplines – this would therefore mean you’re likely to have been “in the business” for at least 5-10 years of “progressive experience” (more likely 10-15):
1 – Program and Project Management (they’re different)
2 – IT Investment Management (i.e. how the CIO’s office operates)
3 – IT Acquisitions (i.e. Proposals, Marketing, Cost Estimating – this is where the SA spends the most time)
4 – Enterprise Architecture (i.e. the enterprise-wide constraints, standards, reference models, templates, reusable assets, meta-directories, etc., from models like the FEAF, TOGAF, DODAF)
5 – IT Architecture Methods and Patterns (i.e. SOA, ITIL, COBiT, etc. – SOA really being required, as well as “Non-Functional” requirements like scalability, availability, etc.)
6 – Systems Engineering (i.e. various flavors of the SDLC, with heavy emphasis of the Requirements discpline)
7 – Business Architecture (i.e. the non-technology elements required for delivery of an IT capability, like organization structure & training, resourcing model, service agreements, facility provisioning, materials and logistics, telecommunications and power, etc.)
8 – System Architecture (i.e. planning and designing the WHOLE system, if even just a little one, like a small website)
9 – Sub-System, Component or Service Architectures (at least a few of the majors, including Information/Data, Security, Integration, Infrastructure, Application, User Interfaces & Visualization)
10 – Programming & Testing (actually having used the tools and environments)
11 – Information Technology Awareness (essentially keeping up to date on the trends and features of IT products, vendors, user demands, legislation, pricing, etc.)
12 – Business or Mission Processes, Functions, Data & Standards (most IT solutions are delivering business requirements, for a particular industry, business function or mission – you should become well-versed in one or a few of these, for example insurance or financial systems, geospatial mapping, inventory management, etc.)
13 – Knowledge Management and Social Media (i.e. knowing how, when and why to share what information with the people that matter)
So, you say, “I can’t be (A) recommended or (B) self-certify myself into an SA role without first immersing myself in the above 13 disciplines – but how do I get into those? I’m only a (insert-your-subdomain)-Architect, after all.”
My answer is as follows, in these 5 critical practices:
1 – Be aware of these requirements, and grab or volunteer whenever the opportunity presents to extend yourself (and thereafter you can “self-certify” with some proof points, and start adding to both your resume and your labels or tags as applied to online postings). Do remain mostly billable, however, and continue to prove your utilization value (i.e. temper your enthusiasm and extracurricular activities with the reality of what the customer is ultimately paying for).
2 – Find and routinely collaborate with, whether formally or informally, recognized “experts” or very successful people in these roles – especially if they’re NOT part of your existing, immediate circle (online groups and communities are really helpful these days) – again, volunteer to help or engage. Ping people like me with legitimate questions or ideas; maybe I know someone helpful to you. If your company is developing an internal Solutions Architecture program, jump on it immediately, or at least get close with those who are building it (for example, I was in one of the first groups of Architects through Accenture’s original Solution Architect program many years ago). Your network is invaluable; much of an SA’s job is not so much determining the answer, as it is finding verified experts who already know an acceptable answer.
3 – Become an expert in (or better yet develop yourself) a company asset, solution offering or methodology (preferably one that many “billable” projects need)…so much so that others begin to see you not only as knowledgeable in that subject, but as an SME by role – an actual asset to the organization. Someone who is presentable to the customer. Write and publish something (adherent to proper copyright and IP guidance of course), that can be used outside of your project – whether inside the company, on the web, to a client group; it doesn’t have to be formal, but does have to be unique and useful (creativity helps a lot as well – Solution Architecture is as much art as science in the end).
4 – Take a stint at leadership – this is very important – you must be able to understand how people and their benefactors work together, remain motivated and productive on IT projects. So although you may be a real gear-head and reluctant to join “management”, find the opportunity to be a team lead, do some project scheduling and resource allocation, push some paper and develop your communications skills.
5 – Become a good writer, and present yourself always as a professional. ‘Nuff said.
In my opinion, and per my experience, if you follow the 5 practices above, and develop a portfolio of experience that covers the 13 disciplines above – you’ve graduated as a real-world-certified Solution Architect open for business.
Leave a Reply
You must be logged in to post a comment.