In the world of online, interactive design for business or government websites, it’s not always clear when the business/interaction designing ends and the IT development begins – or for that matter, how much development is really needed. Even though the project plan might be very clear, governance requirements of the Enterprise IT environment can drive a chicken-or-egg scenario.
While you can’t really finalize the detailed IT design and specifications until the visual design, functional requirements and information architecture are complete…these elements do need to be informed very early and often by some concrete IT direction and constraints in order to be realistic and actually capable of meeting the business requirements. IT investments to support your project also need to be confirmed as early as possible (for example if a new CMS platform is needed), since the lead time for approving, paying, installing, configuring and training activities associated with the new HW/SW may take as long as the entire project was originally planned.
However, choosing IT products too far in advance of detailed requirements approval might result in extra cost and serious system or function incompatibilities. The need for balance between evolving project requirements and the pressure to make the right IT investments and use them appropriately can be mitigated through methodical IT Solution Architecture practices.
An IT Solution Architecture is essentially an abstraction, or a model, of all the IT-related elements that need to be implemented together to meet business requirements within the IT investment context, including the resources that deliver or use the IT-related elements. Think of a traditional “CONOPS” (Concept of Operations) with an “IT Architecture and Plan” overlay, that meets the Interactive Design objectives. This model takes shape very early in the business solution dialogue, conforming to any Enterprise Architecture models that may be available, and evolves as the solution requirements become more detailed – both influencing the requirements and reflecting them. The model can be represented in many ways, for example through illustrations, process flows, checklists, inventories or documented approaches.
This model is then communicated and used, as the business-to-system requirements are completed, to create the technical requirements, finalize IT asset and service investments and to plan the overall detailed design/build/test/deploy phases.
The Solution Architecture guides more detailed development of the domain-specific technical, system and process architectures – for example the overall security, data, integration and storage architectures. It helps the project maintain traceability from the ultimate technical designs, back not only to the business requirements, but to the guiding IT investment context and Enterprise Architecture. This traceability provides risk mitigation to both the project and its overall investment program, and helps ensure a successful testing phase.
Typically as an unintended benefit, use of a Solution Architecture may also improve the overall collaboration and knowledge-sharing environment of the project.
Therefore, the path from Interactive Design to an implemented, successful IT Solution is considerably more efficient and likely more successful at meeting business requirements if a Solution Architecture is involved, preferably managed by an IT Solution Architect with considerable experience in current system architectures and standards, IT systems engineering and interactive IT solutions.
Find out more about Interactive Design and IT Solution Architectures at Navigation Arts, an Interactive Design and Information Architecture solution consulting firm in McLean, VA. Read more about Interactive Design, Information Management, Internet Marketing and Enterprise IT Architectures at the Interactive Information Management blog.
