jump to navigation

Architecting e-WorkPlace Applications for Participation March 10, 2006

Posted by poseidongroove in Bazaar, Chaos, Collaboration, e-WorkPlace, Edge Thinking, eMail Management, eWorkPlace, Mashup, Mashup SOA, SalesForce, SOA, Social Software, Web Services.
trackback

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!

Advertisements

Comments»

1. Tim Villanueva - March 13, 2006

“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”

BRAVO!

It is almost always the better approach! Yes, let’s make technology the slave to the objectives, rather than the other way around.

You know, there is an old adage (well, it’s pretty new, and I wrote it) that says “When someone is able to achieve an understanding of a concept that is beyond that which they understood before, they are likely to believe it”. This is classic for technology, once people are able to bridge the gap in understanding new concepts such as SOA (and then beyond that, the finer details of SOA), they are far more likely to believe it is the way to solve a large # of problems)

(this is also relevant for philosophy/religion, teach it in a way that one has the “ah hah, I get it” moment, there is higher chance of acceptance — it’s all about pride)

You know… when one learns how to swing a hammer, everything looks like a nail!

2. poseidongroove - March 13, 2006

Thanks for the quote need to keep using it as a reality check. Interesting analogy about religion. True we are more absolutist in our thinking than we think. You might enjoy this post. https://poseidongroove.wordpress.com/2006/02/10/epistemic-arrogance-opportunities-and-threats-in-software-development/


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: