It is important to recognize that it is never the case that there is a single “correct” architecture.
Guidelines to Solution Building
The following conceptual guidelines should be considered.
- The definition of a “solution” in the context of River Logic and EO is: A solution is a well-articulated value proposition that compels a client to move forward. Given this definition, a solution might be anything from a dedicated application to a consulting service to a data set. Solutions need to be defined by Domain Experts (DE) and must take a form that is suitable for leveraging the DE.
- Models, especially those that capture a DE’s knowledge for use in an EO-based solution, should *NEVER* be designed to calculate a result. Rather, EO models should be thought of as being analogous to “free-body diagrams” from physics. A free-body diagram is used to represent all the forces acting on a physical system. If you have a free-body diagram for a physical system, you can compute many results, not just one. In fact, with the right inputs, you can calculate any result you want. EO models for solutions must be designed similarly. EO models do not represent a single result calculation, they can (and should?), potentially, represent *EVERY* calculation and analysis that can be made for a given problem domain. In formal terms, we say that EO models are the equivalent of “enterprise diagrams” which are the economic equivalent of free-body diagrams.
- Another way to think about the preceding point is to say that EO solutions have, “infinite degrees of freedom.” This means that any variable can be an input and any variable can be a calculated result. This capability is a strong differentiator for EO solutions.
- EO solutions should not be constrained by conventional solutions. Because alternative technologies effectively force you to design solutions that calculate a limited result set, trying to pattern an EO solution on a conventional solution is a mistake. EO solutions should look strikingly different and they should allow users to “flip” problems around and solve from multiple directions/perspectives. For example, given an EO solution that allows me to specify a given set of inputs to determine optimal outputs, the solution should allow me to change the problem by specifying the desired outputs and solving for an optimal input set.
- EO solutions must protect the intellectual property (“IP”) of the DE. Typically this is accomplished as in our Trade Promotion Optimization Planner™ solution co-developed with AFS Technologies. The user can’t directly access the EO model or EO analyses which effectively constitute the repository of the DE’s knowledge.
- In addition to possessing proprietary IP regarding the manner in which a particular domain should be represented in terms of enterprise diagrams, EO solutions must also capture the DE’s knowledge regarding what an enterprise *CAN* do in a particular situation. A proper EO solution thus includes representations for alternative courses of action that an enterprise can pursue that it is *NOT* currently pursuing. The key issue is that this representation will require data from a source other than the enterprise; therefore, EO solutions must have a means for incorporating data that comes from a source external to the enterprise.
- The DE’s knowledge is dynamic; therefore, EO solutions must support a methodology for updating the underlying EO model and/or internal/external data sets. River Logic’s Dataset Manager (“DSM”) platform is a good example of the infrastructure we need to provide to Development Partners.
- The best solutions will be “Communication Devices” capable of leveraging network effects. This means that all EO solutions should support standardized workflow that allows users to share results by highlighting concerns, opportunities, alternatives, etc.
- *ALL* solutions should support the concept of “multiple scenarios” wherein a user can change assumptions and run analyses to create a new scenario, then compare some number of analyses to gather unique insights.
- Users of EO solutions must be able to quickly identify the assumptions others have made in their scenarios. The best way to do this is through EO’s “factor/ add” structures. Changing the underlying data is never a good idea for many reasons.
- EO Solutions must always include Opportunity Values™. If it isn’t showing Opportunity Values*, it isn’t an EO solution!
Undoubtedly, there are many more considerations that can be included, and I strongly encourage others to add to this list.
Closing Thoughts
In conclusion, it is critically important to remember that EO solutions should be engineered to highlight the differentiators EO enables; therefore, EO solutions should never look like conventional solutions and should never be based on a status quo approach to addressing a domain problem.
*Opportunity Value is the net economic impact of a decision or action.