Welcome to the IDIOM Decision Products Knowledgebase.

alt
 



Recent Comments

    Dynamic Business Applications, Forrester blog post

    Mark Norton  8 July 2010 12:37:35 PM
    http://community.forrester.com/message/6856
    John Rymer wrote:

    "I'm working on research to further define "Dynamic Business Applications", an idea we first published in 2008. I'm beginning to think that the acid test for dynamic applications is being able to change the underlying schema on the fly. I mean adding fields, columns, attributes, and even entire tables without taking the application down and certainly without waiting for a DBA to make the required changes.
     
    Three questions for you:
     
    1. Do you agree that changing schema on the fly separates the chaff from the wheat in dynamic applications? Which other dynamic characteristics more important?
    2. Do your users ask for the sort of rapid data changes I've described?
    3. If so, how do you accommodate them?
     
    I appreciate any and all thoughts on this topic!"

    Mark Norton replied:

    "John, I am assuming that by dynamic business applications you are discussing applications that can be changed by business level administrators or business side analysts – that is, the system is designed to be business changeable without requiring the intervention of the SDLC because of changes to the underlying system image. I promote the idea that the key component of dynamic business apps is the ability to change the rules (specifically, the rules that define business decision making) within apps. To the extent that the decision making is dependent on data, this implies that the data might also need to change, thereby supporting your premise. But note that the business can change the rules to gain business value without changing the data structure; the inverse is not plausible - if the business changes the data without changing the rules, how have they created more value?

    Furthermore, I think that your premise infers the ability to ADD data rather than just change – that is, extensible rather than changeable. For instance, it is invalid to delete data that is being used, and deleting data that is not being used does not add agility. Similarly, needing to change the normalized structure of existing defined data (ie a ‘change’ without addition) is likely to be the result of incorrect structure in the first place, and is an IT issue not a business one. So we are left with adding data. So why would you want to add data? There are 3 possible reasons: it is needed in decision making; it is needed for an entirely new process or capability; or it is needed because an external influence compels it (eg SOX).

    I will suggest that when we are discussing ‘dynamic business apps’ we are putting significant weight on the first reason above. Building entirely new process capability is certainly a requirement for agile development, but this is not normally managed in the business domain.

    The data implied by this topic is the data that describes something external to any given process – and it is both tangible and finite (I will assume that any working data required inside the process is not relevant to this discussion – this should be extensible). We can conceive of gathering all data that is relevant to a domain (for example, standards like Acord, HL7, MDDL, etc try to do this) in which cases the schema is a superset of all data that could be required, and so the schema will not need to change in the normal course of events – we have already defined it all!

    In the larger problem domains, such omnibus schemas are impractical for internal processing or business use in my view due to their extreme size. With millions of nodes defined, the designer needs a multi-year apprenticeship just to be able to locate and understand any particular node with certainty. For the smaller domains (eg if I sell bus seats the total domain data is very small compared to managing a hospital patient episode), it may be practical to collect all available domain data, so the likelihood and importance of data changes to achieving business agility is much reduced.

    So the bottom line is that I would re-factor the premise to say: is it important for business administrators/analysts to be able to extend the range of data that is being collected to support decision making if the decision design requires it. And this implies not just a change to the schema, but to the process populating the schema, including GUI’s and data interfaces. Data interfaces can be made more agile by applying data integration tools that are useable by business analysts or administrators (eg Talend). Agile business defined GUI changes are less easily resolved.

    This is now a much more localized problem. I would suggest that it has an 80:20 feel to it: 20% of the decision model changes require new data, but they represent 80% of the added value proposition of what we tend to think of as ‘business agility’. Idiom has many customers who have gone for years changing rules (eg costing rules that are limited to the available data by definition) without changing schemas. While this is definitely construed as delivering business agility, we do acknowledge that any significant lift in the value of the overall process increases the likelihood of needing some new data.

    There are many ways that you can achieve this. All examples below are ‘business agile’ applications being developed in response to a need to support dynamic changes in automated decision making.

    ·        Model driven development tools are very forgiving of changes to data schemas (we are now using CA-Plex to achieve this on one project in the funds management space – documented here http://bit.ly/9e6Oz5);

    ·        Document centric development environments also do not constrain the range of data that can be captured (we are currently using Lotus Domino to implement a variation on this approach);

    ·        Our own Idiom Forms is a UI that can be extended at design time to include new data in schemas for immediate deployment along with the rules that require it – this is used to build insurance products by business analysts ;

    ·        And by building an interface that responds to the schema meta-data, it is practical to make them responsive to business administrator/analyst level changes. This is the approach Idiom is currently taking to automate a clinical pathway, using the Vaadin toolkit to build a dynamic meta data driven UI.  

    All of the above allow business administrators/analysts to change decision rules – rules agility is the core of the business agility concept; all examples except the first also allow business administrators to implement changes in the scope of data being collected, so that UI extensibility is also an important subset of the overall business agility concept for these examples.

    So, in answer to your question, I agree with James – the ability for the business to change schemas is not an acid test, but it is an important factor. Its lack certainly reduces the potential scale of business agility that can be claimed or achieved."