The role, impact and usefulness of the "Solution Architect" (i.e., "SA" to the "Enterprise Architect" or "System Architect") has been clarifying for several years across the IT Consulting community, particularly given the increasingly complex nature of SOA, Cloud-centric and Multi-Platform solutions required to meet increasingly real-time, agile and resource-constrained business information management requirements. The SA's role is essentially to be the IT architecture, engineering and resource management lead, as an IT solution is first conceived, planned and begins implementation.

Very often, the SA's efforts are initially delivered as part of a proposal - complete with an engineering plan and schedule, high-level system architecture and product list, plus a cost estimate (both labor and direct). This typically assumes the proposals are meeting pre-defined acquisition strategies - i.e. they need to be "Firm Fixed Price", "Cost-Plus", fall as Task Orders under a previously-awarded "IDIQ", etc.

Therefore, the acquisition strategy may in fact be introducing constraints or guidance into proposed solutioning that don't necessary result in the best, most creative and informed solution. The acquisition strategy in effect doesn't result in the very best, informed responses from the IT vendor and consulting community.

Mitigation strategies that government agencies leverage sometimes include early series of "Requests for Information (RFIs)", Industry Days with Q/A sessions, "Draft" RFPs (soliciting feedback before the final is published), Prototype Bake-Offs, etc. There are actually many variations on the theme of soliciting input from the contractor community, in order to produce the most fair, value-add and mission-acceptable RFP. But this is usually after the acquisition strategy has been defined.

In my experience, on both sides of the Federal (and commercial) IT acquisition process (helping to develop and conduct acquisitions, as well as leading responses), a "Solution Acquisition Architect" would be a much-needed addition to the acquisition management team (SAA). This role would essentially operate as a traditional SA, commensurate with IT consulting best practices, but help shape an appropriate acquisition approach (and ultimately the RFP, procurement T&C or contract) in a way that best anticipates the response and capabilities of the IT consulting/vendor community and technology context.

This line of thinking was recently crystallized (to me) after reading the recent FCW Joint Special Report

on the readiness of the Federal Government for procuring cloud services. The series of articles essentially summarize that the Government's current procurement methods, skills and resources aren't yet optimized for obtaining cloud services.

I might go further and posit that the procurement resources aren't only sub-optimal for addressing cloud services, but also for a number of current trends in dealing with information access, visualization and delivery across the traditional firewalls - including SOA integration, open-sourced data visualization and situational awareness, mobile and "big" data management, etc.

One reason the procurement resources are sub-optimal, and tend to result in procurements that are too long, cost-ineffective, too rigid and ultimately not the very best value, is because the role of the Solution Architect isn't standard in designing the acquisition plan and ultimate solicitation. Many times the available technical architects, SMEs, or separately-contracted PMO shops are pressed into service, to generate the RFP language, review the RFIs, confirm the FFP/Single Contract approach.

However, the solution architect-standard methodology and input that might deliver a solicitation (possibly spread among multiple types of awards, and extending or leveraging existing contracts) that is likely to attract the most advanced, real-world experienced thinking and sourcing to the project - simply isn't used.

This of course assumes that there exist Solution Architects and methodology that includes the knowledge of acquisition types, risks, constraints, processes. That's hard to find, especially on the solicitor side of the table. One suggestion might be to establish a program that rotates industry SAs into the Federal Government, for purposes of supporting acquisition strategies, and also to help develop pockets of expertise within the Government procurement community who are aligned with and cognizant of the vendor response communities solution architecture methodologies.

At the end of the day, the right help might be requested in the right manner, from the best available respondents - and maybe the "Cloud Services Procurement" that's been taking 6 months to complete, can be "sharded" more efficiently into reasonable, informed and truly useful procurement options.