Friday, February 25, 2011

Challenges of Authorization in a Software System

While discussing security in a software system, lot of attention is given to Authentication, integrity, availability, authenticity, non-repudiation, and confidentiality. But from this list authorization is missing. For authorization simple RBAC (Role based access control) or its variations are widely used. But RBAC does not account for following major aspects in contemporary enterprise systems:

1. Dynamic nature of business objects – dynamically altering attributes, their meanings, and operations as system evolve and flexible nature of architecture and design (for example systems based on template -,,

2. Adhoc demand of access to business objects by users (humans or machines). For example, in case of delegation.

3. Multi dimensional organizational structure on various parameters (hierarchical, project/matrix based, or process based, geographical expanse, etc). This challenge becomes more complicated with realization that each dimension have its own characteristic such as hierarchical structure is a tree structure, matrix structure is graph, and process based is linear. In real enterprise most probably all organizational structure exist at a given point of time.

4. Negative permissions (not to access or do something). Practically in all of the current models only positive permissions are handled but they are silent over negative permissions.

5. Permissions are given on a business object but if permissions are required over particular instance of object then none of the model is capable of solving this challenge.

Although some attempts have been made to address such complex challenge (for example Capability Based security, Brewer and Nash model, etc). But all of these models cover partial of the challenges stated above.

Friday, February 18, 2011

Does Enterprise need SOA for Integration?

One of the most overlooked requirement in Enterprise as well Integration Architecture is seamless replacibility of enterprise applications ( custom made, off the shelf, Cloud, Enterprise Information System, etc). For example, enterprise XYZ wish to replace Siebel CRM by Salesforce. To achieve this target, Enterprise IT has to develop customizations on Salesforce and integration harnesses with other EISes.

Certainly, customization of Salesforce need to be developed but can Integration harness development is reduced to minimum. If Integration has followed the SOA in true sprit then YES but if Integration has followed SOA by using just Tools and platform then NOT.

Decision is yours.

Thursday, February 17, 2011

Complexities in enterprise IT infrastructure (dev, test, UAT, training, prod etc) landscape

  • Non synchronized down time of systems/Applications
  • Simultaneous development & testing (varying projects) on
  • Satellite systems/applications
  • Integration layer/components
  • Varying number of instances of each system/application (satellite as well as integration layer)
  • Simultaneous presence of multiple integration platforms as well as their multiple versions
  • Continual introduction and retirement of system/application in environment
  • Synchronization of data across environments
  • Growing/reducing data flow within network
  • Continual introduction and retirement of B2B partners
  • Support and maintenance of this cobweb

Monday, February 14, 2011

Numbering System in Message Flow (Communication) Diagrams: Part 1

In any integration project message flow diagrams are one of the most important artifacts along with mapping sheets (among participating systems and CIM- common information model or EBO -Enterprise Business Object).

In Message Flow Diagrams (or Communication Diagram) flow of information depicted and is depicted in terms of numbers for chronological order. This simple number scheme is only good for very simple systems. In any enterprise class systems or integration scenario information may not flow among participating systems in linear chronological order due to asynchronous communication, multi threading, multi processing, clustering, human intervention, etc.
To handle such common scenarios, I have developed a simple scheme which has worked for me in very complex integration scenarios and while architecting/designing products of varying complexities.



Sunday, February 13, 2011

Random Thoughts on Software Design and Architecture

While discussing with my fellow architects and designers, I realized some of us are infected by disease of too much analysis and drive for perfection. This excessive analysis and perfectionist behavior lead to complicated software which can be simpler.

I have summarized my thoughts on this topic in few sentences:

Most of the software to be architected and designed for happy path, and exception paths not for the disaster paths. For disasters one should have disaster recovery plan which must be separate from core software. Software design should strive to bypass the disaster not to handle it.
It is also true that there are some mission critical systems which must try to handle disaster up to an extent. Some of the examples of such systems are space craft, missile, aircraft, etc.

Good Enough is Good.

Saturday, February 12, 2011

Saturday, February 5, 2011

Prerequisites of Successful Scrum

1. Team members are highly or moderately skilled.
2. Team is tightly knit.
3. Information exchange among team members is fast, consistent and free flow.
4. Team is co-located.
5. Business is highly involved with team.
6. Architecture ( Business, Information as well Technical) is well defined.
7. Infrastructure is up and running – Dev, test and UAT environment.
8. Automated build and release.
9. High level of test automation.
10. Team’s dependency on external world is minimum (ideally zero).
11. Participating systems count is minimal.
12. Requirements are stable at higher levels so product backlog has minimum changes.
13. Team members are autonomous to take decision on what user story should be part of sprint/scrum as well as total numbers of scrums/sprint needed to achieve stated goal.

Friday, February 4, 2011

EIS and Integration

While talking to various business and technical architects, I realized that most of them have very confusing ideas behind usage of any enterprise class systems, EIS (Enterprise Information System) like ERP, CRM, SCM, HRMS etc. For most of the persons each of EIS is specialized for some business function and some time domain. This view may be satisfying for business folks but must not be sufficient for architects.
Any EIS serves few of the basic functions:

1. Focuses on a specific business function and or domain.
2. Managing Business objects life cycle.

In any enterprise which has many EISes to accomplish business objectives, need integration. To keep the essence of EIS intact and not duplicating the data across EIS Integration and Information architects has to be very careful. The information flow (essentially business objects transfer from one EIS to another EIS) must be controlled and business objects which have achieved a certain state (in life cycle) in source EIS should transferred to target EIS.

Thursday, February 3, 2011

Operations in a Service Interface v 4.0

Now the fourth version

Tuesday, February 1, 2011

Book Review: Cloud Security and Privacy

Book Review: Cloud Security and Privacy by Tim Mather, Subra Kumaraswamy, and Shahed Latif: Publisher- O'Reilly: ISBN- 13: 978-0596802769

Cloud Security and Privacy by is one of the first book which focuses on security, privacy and Audit need of Cloud Providers as well as consuming enterprises. As rightly stated by authors in Preface book is targeted to business personnel who are concerned with processes and methodologies rather than dirty technical details.

Book covers security aspects – Data and Network in detailed manner in initial chapters and then shifts to Privacy and Audit.

For such a vast subject certainly couples of hundred pages are not sufficient but book is a good and successful attempt in right direction.

In the end of book authors has provided sample/template of SAS 70 and SysTrust Reports. The book also covers Open Security Architecture for Cloud Computing in very short and concise manner.

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: A competing book is Cloud Security - A Comprehensive Guide to Secure Cloud Computing by Ronald L. Krutz and Russell Dean Vines

One can get more information about book and related topics from:

1. Amazon:
2. Publisher – O’Reilly
3. Book webcast
4. Book Review
5. One more review
6. Review:
7. Review:
8. Review: