Overview
Technical architecture is the crossroads of all software projects, combining the business objectives, user experience, and infrastructure, and bridging the requirements, custom and off-the-shelf capabilities, design, and development plan.
With so much responsibility, it is no surprise that it is the technical architecture that often defines the success or failure of a project.
Challenges
Many projects do an upfront technical architecture that becomes a “write-only” document to reiterate the project goals, requirements, and technologies selected. At such a high level, and without an ongoing tie into the actual progress, such an architecture provides little real value.
Architecture is as much art as science and is highly dependent on the experience of the architect. Many architects have great instincts, but an inability to explain and document them; other architects are well-read and can communicate effectively, but lack the instincts and real-world experience to know where the pitfalls are.
The real limitation is that the technical architecture is not influencing development teams, because it is too disconnected from the development processes, including Agile Methods, like SCRUM.
Our Approach
Logifusion provides this service on-site, with the possibility of some off-site periods. This is due to the need for a high amount of contact with the team – architecture is as much about communications as it is about content, and at their best, architects are constantly available to guide the team, remove doubts, notice issues, evaluate prototypes, recommend alternatives, etc.
The Logifusion approach takes an “engineering” view of architecture, focusing on the value delivered to address near-term issues and influence the development of real systems. We call this approach Agile EA. Through Agile EA, the EA organization delivers information in a way that can be integrated into the software development team processes. This involves computer-readable and testable specifications for models, interfaces, and integrations rather than paper diagrams.
This involves building a governance process that uses the component management and artifact delivery technologies in use within the development of this. This involves establishing a virtual Systems Integration Testing (SIT) environment, so the system-of-systems issues typically in the realm of EA can be expressed, tested, and verified in the realm of continuous development.
The Logifusion approach emphasizes evaluating risk and reducing it early through an explicit innovation process. This can take the form of prototypes or conference-room pilots but manage as a project with explicit goals, timelines, and resources. Customers often call the innovation program, a Center-of-Excellence (COE), and use the COE to provide experience-based decision-making on how technology will be adopted.
This provides significant value over a technology decision based on a paper study or a generic evaluation that does not take into account the current technical architecture and its roadmap.
Technical Architecture is not a one-size-fits-all solution for the enterprise. The architecture should focus on managed choice and compatibility of those choices. So a system that needs, for example, a document management solution, does not always have to take the most high-tech product in the Technical Architecture and be saddled with an unfavorable cost-benefit ratio, more system complexity, and increased risk.
These choices can be governed through tools that development teams use to manage component dependencies, e.g., Maven provides a means by with the Enterprise Technical Architecture is managed through a repository that can be integrated into continuous integration and development processes.
Measurable Outcomes
Examples of the deliverables provided in this service:
•Agile EA training (formal or informal).
•Early adopter project selection and jump-start, by establishing a CoE project for technology innovation.
•Establishing Technical Architecture repository.
•Establishing managed choice and compatibility in the repository to offer systems a low-, medium-, and high-tech alternative to component needs.
•Establishing development-friendly governance and integration testing infrastructure.
•Mentoring development team members on architectural capabilities.