Identifying Capabilities, Risks, & Mitigation Strategies
The purpose of a Technology assessment
The intent of a technology assessment is to provide a clear definition of where you stand today with your technology. We refer to this as "Point A", meaning where you are now. Once you are clear about Point A, then achieving Point B (or where you want to go) becomes tangible and that much closer to reality. An Assessment is foundational for transforming any existing system or application, enabling a strategy and path for building the next best solution or deciding whether to buy vs. build. An Assessment also identifies technical debt and major architectural changes that may be needed to take the business forward.
Technology assessment deliverables can include:
Aspect – feature or trait of a system that span all parts of the system.
MVP – Minimum Viable Product (MVP) is the scope that provides just enough business value to deploy to users/customers, yet does not add unnecessary features before getting the product out and receiving real user feedback.
- System Architecture diagram and narrative. The architecture concepts should be solid, and the scope of what needs to be addressed should be comprehensive, but the detailed design and implementation will change as more detailed requirements are established.
- List of system-level features being addressed (aspects vs. user features) such as metrics, versioning, testing, deployment scale, load limiting, support for extensions, off-line capabilities, etc.—with an overview of how it is addressed in the architecture.
- Early Assessment of risks that should be addressed near-term (might also include assumptions, unknowns, etc.). This will include a priority list of what should be prototyped early on, if doing new development. ‘Early’ meaning the list can change as we dive deeper into requirements in the next iteration or engagement.
- Recommendations and Next Steps in the form of a statement of work proposal, including recommendations on how to engage existing resources.
Risks are the most important items to identify and quantify when prioritizing work. There are various strategies to address risks. It may be necessary to create software to demonstrate a proof of concept. On the other hand, a risk item may best be addressed by digging deep into existing code. Many times it is a process of discovering how the business is affected when making trade-offs between features, time and expense. Categories of risk include:
- Business Case Risks
- What are the business factors that will influence project success?
- Organizational Change Risks
- How will changes to capabilities and workflows impact internal resources?
- Technical Risks
- What is the initial Client scenario, and what changes are required?
- Functional Design Risks
- How much of the current base UX design can be used or replicated?
This assessment includes taking time to list as many risks as can be identified, and time permitting, marking each with a mitigation strategy. The resulting mitigation paths may include:
- Metrics — rather than develop solutions to imagined issues, do the simple thing and add metrics to measure the issue and provide data-driven improvements.
- Research — how others have addressed the challenge and borrow where appropriate.
- Rapid Prototyping — create several solutions as working prototypes and perform ad-hoc usability testing to mitigate the risk.
Understanding and assessing technical debt, or "code debt," early on can be an important way to establish project goals and direction. While it is preferable from an engineering perspective to choose the correct solution to a problem, compromises are often required to develop the best solution from a business perspective.
Technical debt is the difference between what was promised and what was actually delivered. This includes any technical shortcuts made to meet delivery deadlines!
When choices have been made in the past that have resulted in significant limitations to functionality or scalability, our team will work with you to carefully untangle business requirements from technology constraints. We help you to avoid over-engineering without undermining the success of your product or application.
Rewriting a large software product is a major investment and must be offset by an equally large benefit. The main benefits are typically realized by using modern updated technologies and by creation of a more thoughtful architecture based on experience and hindsight, balanced with new thought leadership, and challenging the status quo.
These technologies bring tangible business advantages:
- Define a modern technology strategy and plan of execution
- Support cloud-based customer or user demands
- Demonstrate real tangible progress in development
- Enable deployments in weeks instead of many months
- Eliminate constraints of existing architecture
- Focus on new customer growth needs
- Reduce complexity, in comparison to existing Architecture
- Create a lighter-weight technical footprint
- Create reusable shared services in the cloud
- Eliminate unnecessary components and redundancy
- Challenge status quo in all areas
- Understand what is required to be consistently reliable
- Use modern tools, technologies, and networks
- Include redundancy, software upgrades and patches
- Support offline requirements and capabilities
- Improve management, monitoring and security
- Flexibility and Extensibility.
- Provide lighter-weight flexibility and less complexity
- Features and Functionality.
- Make sure the product has the right features and functionality, incorporating strategic business vision
- Integrate contextual customer intelligence, e.g. social media
- Engender loyalty and high customer appreciation
- Migration and Upgradability.
- Provide a revolutionary cloud-based solution for new customers.
- Migrate existing users to the new architecture
- Leverage modern tools, technologies, and networks
- Provide significant incentive for existing customers to upgrade
Aspect Oriented Architecture & Design (AOA/D)
DVmobile begins technology assessments by identifying the requirement types that a new platform must address. The initial and primary focus is on 'aspects' of the system's features. 'Aspects' are traits of a system that span all parts of the system. As such, they cannot easily be 'plugged into' the system later on; they are 'baked' into the architecture. This is the primary reason systems must be re-written: to add or enhance 'aspects' of the system.
Sample aspects include:
- Error handling
- API architecture
- Automated testing
- Database architecture
- Support for extensions
- Offline capabilities
- Deployment scalability
- Auditing/data security
- Load limiting
- Debug-ability in production
- Usage billing
It is imperative to uncover all the 'aspects' that the system must perform in order to create architecture to support them. In the initial assessment phase, we make high-level assertions, along with a cursory assessment of the state of the technology available. Determining the real requirements of each, however, requires deeper interaction with developers and business stakeholders in your organization.
By carrying out these tasks with deliberate prioritization, the final architecture can be designed to accommodate new and future features and support any modules that the system provides as functionality to end users.
Reach out to us today to discuss your modernization needs, we can carry out a Technology Assessment to help you discover and decide your next steps.