Back on this blog for John Rymer of Forrester talking about dynamic business applications (about which I have blogged before) and how the next generation of systems will be designed for people and built for change. John began by showing a video of a broker’s desktop demonstration built by Adobe and some partners. Brokers are interesting because they typically use 20+ applications. John uses this demo because he has not been able to find a single application that is in production that meets the requirements for this new kind of application.
The demo was very seamless, lots of moving between forms, graphs, comparison tools in the context of a rules-driven process that made sure it was right without being inflexible. Secure email, documentation collection and generation, product comparison all done in a single desktop. Key elements included:
- User never left the workspace, everything is done in the same context
- The tasks maintain context as they execute e.g. by only allowing them to sell products for which they are licensed
- The application did lots of work in the background to support a successful outcome like finding documentation, filling out forms etc.
- The application had some social media features like shared web sessions
- Existing services drove the application and were assembled and used
There are four principles for Dynamic Business Applications:
- Processes, tools and information you use reflect your work’s context (design for people)
- You will work in a single workplace not disparate tools (design for people)
- The business processes you use will adapt to changing business conditions (build for change)
- You will be able to evolve your applications as needed while preserving integrity (build for change)
This build for change is really build for continuous change – perhaps automatic response to change (rules and analytics that make different offers in different circumstances for instance) or rapid declaration of a new or changed process. Both of these require rules and process to be extracted and externalized so they can be managed more effectively and with agility.
A variety of applications will get developed with most organizations starting in one area.
- Some will use BPM to build processes for rapid modification and extension.
- Some will develop processes that adapt to changing conditions using rules and analytics
- Some will focus on contextualizing information and processes for a group of people – workplaces
- Some will develop short-lived situational applications
The first two groups often “find” each other as folks doing BPM often find that decision management is critical and vice versa. Decision management and process management are very complementary.
The drivers for this change are pretty clear – globalization, outsourcing, skills shortages, regulation, margin pressure and more contribute to change and productivity pressure. Change is faster, more dramatic and more disruptive than ever before – not just the usual better, faster, cheaper cycle but much more. Productivity is being killed by application switching, figuring out how to use tools for, say, sales management to manage customers etc. – there is a real need for workplaces that allow someone to focus their efforts.
Context-driven is an interesting concept. More than just personalization but also role-based, expertise, activity, processes and goals. Each layer contributes to more business impact. Designing applications to flex – to have flexi-points – will also be critical. These can be built into any layer – within the workplace, within the process, within business services or within the integration layer. Decision services, to me, would be an obvious and effective place to build in this flexibility. Clearly BPM is an approach to build flexi-points into process definitions and SOA an approach to build it into the integration layer.
This approach of designing for people and building for change will drive job changes.
- Business analysts will become “business architects” who bridge IT and the business or Process / Rules Designers.
- Designers will focus on designing workplaces or will become “Devigners” – a mix of developer and designer
- Application developers become assemblers or process/rules implementors or perhaps devigners
- Systems developers become focused on developing services, schemas, vocabularies
The most aggressive adopters have agile development teams with both business and IT folks working together – the business and IT will work together more closely than ever. Business people will maintain more rules and build more processes. But to make this work the business and IT will need a “common currency” so they can communicate. Things like business rules, decisions, policies, process steps, business services can be part of this shared vocabulary.
Collaboration is required but how much is a question. IT must provide not just object models, architecture and programming but also tools and templates that allow the business the power to make changes. Business users must become more comfortable with authoring, testing, designing and evolving applications. This is going to be uncomfortable for both sides but is increasingly a business necessity. It will take some confidence building steps but it must be begun.
Dynamic Business Applications have a different focus from transactional ones:
- Processes not transactions
- Dashboards, alerts, workplace not a page or form
- Adaptive not data integrity as a focus
and more. John’s advice to the business folks in the audience was clear – take your IT partners to breakfast. Discuss different and common terminology, discuss how to share the design and maintenance of systems, discuss the tools and training you need, find out what IT needs from you and come to a future vision for applications in your organization.
