Overview

LogiFusion Consulting Strategy and Architecture strategy services use proven methods to implement shared service strategies and develop designs and roadmaps for a more cost-effective and agile future-state architecture. Inevitably, there comes a time when having a set of fresh eyes on a system helps provide a needed insight on the viability of the system development and value to the enterprise. Typically, these are considered to be high-level reviews of documents and interviews with stakeholders and developers. Perhaps there is a demonstration of the system or a quick review of some aspects of the system technology design or application architecture. Too often, these reviews are done by “high-level architects” that have never developed systems or haven’t seen code in years, much less written any.

Challenges

One challenge in a meaningful Independent Architecture and Design Review (IADR) is in its comprehensiveness – an ability to connect the highest levels of the systems architecture to the lowest levels of design patterns and implementation and testing. This comprehensiveness does not require a multi-month study of the system but does require a consultant that is comfortable with all levels of systems architecture and technology development.

Another challenge in a meaningful IADR is its relevance – what decisions are the customer trying to make, and how will the information in the IADR support that decision-making process? Typically, system reviews are driven by a flat and static template that tries to answer a vague question of system quality – is the system flexible enough, or is it well built, or will it scale?

The vagueness not only calls into doubt the utility of the IADR results but calls into question the motivation for the IADR. Is it a witch-hunt? Everyone involved gets defensive and guarded with information, and this further interferes with the value of the effort.

Our Approach

Logifusion provides this service on-site or off-site, with expert consultants with years of experience using a Scenario-Based IADR methodology. In a scenario-based approach, the IADR is seen as the means, not the ends. The ends are described by 5-20 scenarios describing what the organization is trying to confirm.

For example, the vague question of will the system scale becomes a scenario of how will the system support 20,000 simultaneous users. The scenario analysis may confirm that the system as is will support that usage, or the system will support it through some hardware or component changes that are anticipated in the design, or the system has a design weakness that needs to be refactored to accommodate that usage.

The focus on scenarios makes the IADR effort more relevant to the customer and more understandable to the stakeholders and developers that participate in the analysis. This is further enhanced by the credibility that is provided by the deep hands-on experience of Logifusion consultants that have lived the real world of programming and can connect the dots between the architectural intentions and the implementation realities.

This results in a very open and transparent analysis often seen by the developers and stakeholders as a welcome and useful enhancement to the development process. Knowing that the IADR may lead to a refactoring plan that can actually be implemented versus a set of pie-in-the-sky ideas that cannot be translated into execution, makes the IADR analysis and results part of the continuous improvement process employed by Agile EA and Agile Development teams.

Measurable Outcomes

The result is a dramatic increase in the effectiveness of IADR process, leading to more effective systems development and deployment.

  • IADR Scenario formation workshops.
  • IADR Analysis activities, including systems architecture, application architecture, design, coding, testing, and development environment and processes.
  • IADR Actionable Recommendations. Near-term recommendations are in the form of a development team refactoring plan; long-term recommendations are in the form of a systems release roadmap.
  • Briefing to stakeholders and participants.Illustrations of key concepts of the recommendations through actual design and code changes.