Architecting e-WorkPlace Applications for Participation

I’ve had a very busy last few weeks practising what I preach. Before I launch into my muse, a friend asked me why I don’t go deep and dirty into technical details on the blog. If anyone else is wondering, it’s because I also have a business audience trying to understand our thought process as it relates to application design, expressed in a way they can grasp(Even though sometimes, I forget about this). So I’ve been integrating Salesforce.com into a Global Marketing Collaborative WorkSpace for an Investment Bank in the City.
In summary, the sales guys use salesforce.com to create sales opportunities on the road with multiple devices, (Micro View). Managers and sales support team use their Global Marketing Collaborative team rooms to review, approve and discuss the macro issues related to each specific marketing request (behind the corporate firewall).
The integration piece is relatively straight-forward, I call it “Right Coupling” Salesforce generates an email of the captured opportunity in simple xml tag name value pair format as each request is being created.

Each unique request is sent by email to a specific context in the Global Marketing Workspace. The context, in each case, is a regional dashboard of Marketing Requests RFP e.g. Japan. A Jython scripting event is subscribed to each context listening for incoming emails. The event is simply a “Search Agent” looking for anything that matches specified criteria.
The Jython event picks up the incoming XML name value pair metadata in the email and creates a team room for that specific opportunity using the values in the email as attributes.
The team room includes a discussion forum, document templates and task list. All cases are viewable in a dashboard. They can be sorted/filtered by status and whatever else anyone fancies.
This simple integration solves a problem most companies might be facing today when faced with integrating several applications that on the surface have similar features. As an architect, you need to pay attention to the following:-

• Context of Use – What categories of users love using a particular application and why? You simply can’t implement new technology for technology sake. It also applies to design patterns. If email is sufficient use it.
• Macro/Micro View – It’s important to appreciate where detail and summary information needs to reside. In this case, it was obvious that it needed to be in SalesForce.com The managers only need access to summary dashboards, sales support need access to emails, tasks, documents and everything else related to the case.
• Confidentiality – Even though On Demand platforms are brilliant at what they do, there is a segregation of duty between externally hosted applications and internal applications. In the case of banks and pharmaceutical, it’s easy to tell what belongs where.
• Creating a Context for Exception Management – Very few companies pay attention to exception management when implementing applications. This is where the most value is created and significant knowledge about process exists. A collaborative environment is better suited for managing the conversation thread around any exception that relates to that opportunity. Think of forums, WIKI, and Document Templates Library.

Why am I writing about this? I’m a big fan of top heavy command and control architecture, reference architecture name it as James McGovern described it in a recent post. However, what I’ve come to appreciate in my entire career in IT is that creating an inclusiveness culture in application design invariably makes them pervasive. You will quickly realise a return on your investments in these assets. I’m not talking about machines when I say assets, I mean people. People in companies increase the value of the brands. You need their collective assets, Organisational Memory to give meaning to your business. It therefore follows that you need to architect for participation. An environment where thoughts and ideas can flow sits comfortably with command and control applications such as ERPs, CRMs and Sales Force Applications.
For this customer, it would have been easy to say use an ESB/Web Services/SOA whatever to mediate the messaging between the two platforms however, as with everything else in our sphere of work, a pragmatic approach might often be a better approach. It’s also possible that the customer wants to move to a more secure alternative that assures guaranteed message delivery.
Everyone including moi knocks emails. As you can see in this example, email is not only a powerful medium of communication; it’s also a low cost and effective integration mechanism.
When architecting enterprise applications, think about barriers of entry for end users. User adoption and user participation invariably decide how pervasive any application is. Our mission now is to take SOA beyond UDDI directories to become browser icons. My next post is on Collaborative Services Description Language. (CSDL) an idea I’ve been working on that I believe will enable end users to compose and orchestrate services from their favourite applications. (At least that is the hope). I would also call it a unified service interface for social networking. AKA mash up SOA!