Choreography in Business Systems

Most of the current computer systems (from software perspective) work on two core principles:

1. Deterministic Model
2. Centralized control
3. Feedback system
4. Optimization at component/Sub System Level
5. Evolution Proof

Deterministic systems hate uncertainty. In most of the cases logic boundaries are predefined.

Today’s most of business systems are built around centralized control where one piece of code directs others to act in particular fashion. In this scheme essentially all logic is confined at one place, interacting parties are just slave without brain. This approach keeps system simple on overall basis.

Most of the business systems do not use feedback system (If they use, they go for periodic feedback not on continuous basis). More over today’s feedback systems assume that there is one correct way, if deviation occur feedback will try to correct the system. Essentially designer of system assumed a perfect correct position. System cannot go beyond that level of correctness.

We simply assume that if individual components are optimized then system will be optimized. This thought does not leave any room for redundancy, fail over in the system. We like to make system as lean as possible to achieve high performance.

Though we understand concept of evolution but in today’s computer system, evolution is creator driven.

All of the five points mentioned above make today’s computer system not fit for Choreography. Choreography requires flexibility
All the five points above mentioned make computer system rigid, high performing and evolution proof. For choreography systems should be based on Probabilistic Model, distributive control to contain error/exception conditions, evolving feedback system which is based on increasing correctness, system level optimization and open to evolution.
But:

1. Does business need such systems?
2. Do we have capability in terms of sustenance of self evolving business processes?
3. Do we have such high level of computing capability to support such system?

So, do we need Choreography in business systems? Is SOA ready for Choreography?
Reference: 

1. http://architecture-soa-bpm-eai.blogspot.com/2009/01/orchestration-choreography.html
2. http://architecture-soa-bpm-eai.blogspot.com/2009/03/services-orchestration-design.html
3. http://architecture-soa-bpm-eai.blogspot.com/2008/12/enterprise-soa-reference-architecture.html

Webservices for eighth grader

Son: What is web service?

Father: It is a mechanism for computer to computer communication. This communication is independent of make of computer and its operating system. So Windows machine can talk to Apple machine or to Linux machine without any heavy duty translation. Webservice enforces one language across variety of machines. More over this language is readable by humans as well.

Son: Hmm… So which language it enforces?

Father: Let me correct myself. Webservices do not enforce common language but common script. Like Devnagri and Latin are writing systems, scripts to various languages. Devnagri is used to write Hindi, Gujrati, Marathi, and other languages. Latin is for English, German, and French. For Webservices based communication Script is XML and various languages are WSDL, and SOAP. So XML is a system by which one can create new languages.

Son: It is OK. But then how actual communication happens between computers using web services?

Father: Let us make an analogy. You know, how we listen and how sound travels.

Son: Little bit.

Father: No problem. Let us build a scenario. You are asking questions and I am answering them. So you are Client or Customer and I am Provider or Server.

Son: It is easy. One who asks question is Client and one who answers the questions is Server.

Father: Perfect. Let’s move on. We are talking in English. So there is contact between me and you which says that you can ask only in English and I can answer in English. So there is contract between Client and Server. This contract in web services world is defined using WSDL – Web Service Description Language. WSDL also defines what questions a client can ask from Server. Because Sever cannot answer all questions in world, its ability is limited.

Son: It is getting complicated, but still manageable.

Father: Good. Now when I and you are talking we are using air as medium.

Son: Yes, I know it.

Father: In Webservices you can replace air by HTTP. Just think of browser address bar.

Son: Oh! Yes. I see http with your blog address in browser address bar whenever I open browser on your laptop.

Father: You are smart. One more thing, yours and my ears can hear sound if are within certain frequency range. Can you hear sound from dog whistle?

Son: I know humans can hear sound waves which fall between 20 Hz to 20 KHz.

Father: That’s good. You should get good grades in Science.

Son:Thanks .

Father: So, there should be something similar to frequency range. It is SOAP. This is something which defines how information is packed, flowing over air – HTTP.

Son: Cool. It is very straight forward. Script which defines language is equivalent to XML. Contract between client and server is WSDL. Information pack is SOAP

Father: Fantastic. Now you know what Web Services is.

Are we still living in Waterfall era?

Project Closure Documentation

While going through PMBOK about Project Closure Phase (Project Integration Management --> Close Project and Phase), I realized that output of this phase requires:

1. Final Product, Service, or Result Transition ( very obvious)
2. Organizational Process Assets Update ( again very natural)
       a. Project Files: Documentation resulting from the project’s activities
        b. Project or phase closure documents: Documentations indicating successful or not closure of project
        c. Historical Information: Historical information and lesion learned.

At closure look reveals a glaring gap (especially for software oriented projects), there is no wish list for next iteration. Both Functional and non functional (technical as well) are important. This gets more spot light with agile methodologies.

A close survey of various Software service providers ( USA as well as Indian biggies) reveals same gap in their mandatory and recommended documentation list as well.

Does it reveal that we are still living in Waterfall era?

WSDL Architectural Patterns

While working with Webservices, we all invariably encounter WSDLs. As Software architect and Designer I have noticed four distinct types of WSDLs.
1. A business entity do various operations

2. A business entity do one operation

3. One operation for various entities

4. Various operations for various business entities

Each pattern has its own pros and cons. Except option 3, all are widely used. Salesforce Enterprise WSDL follows option 2 while Oracle AIA is big fan of option 2. Lots of home grown applications in enterprises uses option 2.

For detailed list of operations in webservice refer: http://architecture-soa-bpm-eai.blogspot.com/2011/02/operations-in-service-interface-v-50.html

Contemporary non function requirements of a Software Product – Part 2

With feedback of my blog readers and my learnings, I have added few of the # 27 to # 32) non functional requirements.

In any software product one has functional and non-functional requirements. It is always easier (is it so?) to identify and define functional requirements. But not so easy to define non functional. With increasing experience of software development communities, traditional non functional requirements like availability, usability, robustness (http://en.wikipedia.org/wiki/Non-functional_requirement) becoming commodity. But with changing business and technological landscape, new set of non functional requirements are emerging.

1. Open API ( synchronous and/or asynchronous)
a. Remote Object
b. Service (for example)
i. SOAP based Web Service
ii. REST Based Web Service
iii. JSON based web service
2. Multiple Channel Access (for example)
a. Connected Desktop (web browser)
b. Disconnected Desktop
c. Mobile application
d. RSS/Atom
e. WAP
f. Mobile browser
3. 3rd party/partners can build on your platform/product
4. Product as vehicle for 3rd party content
5. User as editor of relevant content
6. Content is made available to user when it is ready (push mechanism or at least reactive alert)
7. User add ancillary data ( like rating, reviews, ranking, link submission, recommendations, etc)
8. Settings/configurations can be exported and imported
9. Allow product to run as slave as well as master while integrating with other applications
10. User as owner of identity
a. Published Privacy policy with some control to end users
b. Authentication and authorization using industry wide acceptable standards ( like OpenID, facebook Id, google ID, Yahoo ID, etc)
11. Variable licensing options (for example)
a. Transaction based
b. Revenue sharing
c. User based
d. Fixed onetime cost
e. Time based
f. Cloud compliant
g. Processor based
h. Virtualization compliant
12. Social Networking features
13. Serving high band width as well as low band width environment
14. Information and data search capability
15. Domain Specific language
16. Framework for customization
17. Support distributive SDLC with multiple out sourcing partners
18. Hardware independence
19. Place for online advertisement ( like google ad)
20. Open to migrate to cloud or to non cloud deployment
21. User Analytics
22. Dash board
a. Users
b. Administrators
c. Maintenance and support staff
23. Hooks to monitoring tools
24. Early release and flexible design & architecture to modify
25. Concepts of Roles and Permissions (Identity Management)
26. Multiple Browser compatibility
27. Reporting Requirements
28. Audit Tracking
29. Multiple level of authorization
30. Certification Requirements
31. Compliance Requirements
32. Automated Unit testing just after deployment

Reference
1. http://en.wikipedia.org/wiki/Non-functional_requirement
2. http://en.wikipedia.org/wiki/List_of_system_quality_attributes
3. http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.html
4. http://en.wikipedia.org/wiki/Requirements_analysis
5. http://en.wikipedia.org/wiki/ISO/IEC_9126
6. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749
7. http://architecture-soa-bpm-eai.blogspot.com/2010/10/contemporary-non-function-requirements.html