Scrum: Beautiful and Ugly

Beautiful Scrum: Exists only in theory

Ugly Scrum: Real life Scrum

Exception/Fault and Error Handling and Ontology in SOA

In any SOA enable environment (Enterprise as well as Product) Exception/ Fault and Error Handling forms one of the major areas during Architecture & Design and Governance (especially Design and Run time).

Before moving forward let us set some definitions:

1. Exception/Fault: These are the business and system conditions which can cause temporary or permanent disruption of instance of service/s. In most of cases this disruption is temporary and with some efforts (run time only though coded at design time) service instance remains alive and keep on serving the clients.

2. Error: These are the life killing system conditions which not only kills a very particular instance of service but may also affect deployment of service. There will not be any run time recovery. The best one can expect is graceful death.
In any SOA enabled environment, typical service interaction can be depicted as:

In this diagram the service under consideration is MyService which is calling right hand side service and being called by right hand side service in some business orchestration.

For Exception/Fault and Error occurrence perspective, exception/fault or error can occur in MyService, or called service or calling service.
For brevity let us call Exception/Fault and Error just Exception. If separation required in Exception/Fault and Error then Exception/Fault and Error will be mentioned explicitly.

As a good exception handling practice any exception occurring in any service should be handled in that service and should be resolved there. If resolution is not possible only then exception should propagated to calling service.

For Ontology perspective, exception can be divided into two broad categories:

1. System
2. Business

And if we go into details of each exception then an exception object (sic!) should have following attributes:

a. Exception Group: most of the applications like to group exception for the resolution and notification perspective.
b. Exception Type: Exception, Error, Warning
c. Internal Exception Code: Code to be used by service internally for logging and identification
d. External Exception Code: Code to be used by calling service
e. Detailed Description of Exception
f. Reporting time for Exception
g. Possible Corrective Action/s
h. Severity
i. Service ID
j. Instance ID: of Service
k. Business Object Name: In some cases/implementations payload and/or stack trace may not contain business object name.
l. Stack trace
m. Payload

The code for exception can follow following nomenclature

How to infuse Security in SDLC

In most of SDLC methodologies (traditional or agile) security is last thought requirement. But as security cyberspace is swamped by lot of security threats, security requirements need to be infused in SDLC as soon as possible and must be tracked as diligently as any functional requirement.
To infuse security requirements in any piece of software, I generally follow a simple rule. Embed Security requirements as early as possible in SDLC.
I have tried illustrating this thought in following graphic.

I understand this illustration is very simple depiction due to variety of SDLC methodologies followed but something is better than nothing.

Book Review: Beautiful Architecture Leading Thinkers Reveal the Hidden Beauty in Software Design

Book Review: Beautiful Architecture Leading Thinkers Reveal the Hidden Beauty in Software Design by Diomidis Spinellis , and Georgios Gousios: Publisher- O'Reilly: ISBN- 13: 978-0-596-51798-4
Beautiful Architecture book is loosely coupled collection of articles from industry veterans. Book starts with very basics like what is architecture but then deep dive into more complex and intricacies of software architecture. This book is certainly not for green horns.

The book is to be read in non linear fashion. Read first chapter and then on the need and requirement basis, read the respective chapters. I am not going to that what each chapter does which you can get from Amazon or O’Reilly or other reviewers.

As one of the reviewer at Amazon said “too many cooks” and “half backed”.

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.


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

1. Amazon: http://www.amazon.com/Beautiful-Architecture-Leading-Thinkers-Software/dp/059651798X
2. BookMooch: http://bookmooch.com/detail/059651798X
3. Publisher – O’Reilly http://oreilly.com/catalog/9780596517984/
4. Book Review: http://www.spinellis.gr/blog/20090204
5. One more review: http://millionchimpanzees.blogspot.com/2009/03/beautiful-architecture-leading-thinkers.html
6. Last one: http://www.i-programmer.info/bookreviews/10-software-architecture/155-beautiful-architecture-leading-thinkers-reveal-the-hidden-beauty-in-software-design-.html

Cloud Criticism

While whole of IT industry is behind Cloud Computing. But are we paying enough attention to dangers of Cloud Computing! Most probably not. I have tried to list few of the points:

1. Lock in of data in proprietary format.
2. Lock in of business processes in third party systems.
3. Lost control over business data and its presentation (Recent spat between Wikileaks and Tableau).
4. Always on network which is in contradiction of “Eight fallacies of distributed computing”.
5. Very few cloud vendors.

Reference:

1. http://www.dbta.com/Articles/Editorial/Think-About-It/Environmental-Group-Targets-Cloud-Computing-Criticism-Justified3f--66406.aspx
2. http://minutiaeetal.wordpress.com/2008/10/25/three-critiques-of-cloud-computing/
3. http://www.riorevuelto.org/site/index.php?text=view&id_articulo=5418
4. http://www.informationweek.com/cloud-computing/blog/archives/2008/10/cloud_computing_4.html
5. http://www.museumstuff.com/learn/topics/cloud_computing::sub::Criticism_Of_The_Term
6. http://gcn.com/Articles/2009/09/14/Reality-Check-cloud-computing-as-red-herring.aspx
7. http://www.cio.com/article/498795/A_Great_Cloud_Debate_Zittrain_Counters_CIO.com_Criticism_
8. http://www.zdnet.com/blog/service-oriented/cloud-computings-earthly-bonds/1114
9. http://www.webpronews.com/topnews/2008/09/29/open-source-guru-rails-against-cloud-computing-%E2%80%98hype%E2%80%99
10. http://www.infoworld.com/d/cloud-computing/busted-three-myths-cloud-computing-098?page=0,0

Simplicity

Recently, I was asked to define simple system and hence simplicity. I realized there that defining such simple (sic!) concepts requires lot of intellectual stress and time. Fortunately, I bumped to a small video by George Whitesides at TED ( http://ted.com/talks/george_whitesides_towards_a_science_of_simplicity.html) in which he talks about simplicity. After taken cue from George, I realized that a simple system (or thing or concept) exhibits following characteristics:

1. Predictable/Reliable: System/thing must be highly predictable and reliable to ensure consistency.
2. Cheap in monetary terms: Must be cheap so newer innovations can be build over it
3. Intellectually Relaxed: Things/concept/system must be have large target population
4. High Performance or value/cost: Value delivered and cost incurred ( in terms of money, time and intellectual stress) must be sufficiently low to make it attractive
5. Stackable (Building block): Things must be able to act as building block in a larger and/or complex system.

Virtualization Taxonomy

Hierarchy of Dashboard

1. CXO Level
a. High level information
b. Summary of highly complex business processes
c. Summary of high business impact events
d. Optimized for smartphones/tablets
e. Should be able to notify business managers
2. Business Manager Level
a. Department level information
b. Summary and detailed information of processes
c. Summary of high and medium business impact events
d. Notification mechanism built in
3. Line Managers
a. Line level information
b. Business application focused
c. Optimized for workstation
d. Notification mechanism built in
4. Maintenance and Support Staff
a. Focus is on technology
b. Application as well as process centric
c. Notification mechanism to staff
5. Infrastructure Staff
a. Focus is on technology
b. Infrastructure centric
c. Notification mechanism to staff

Operations in a Service Interface v 3.0

I have listed the operations a service should exposes in my earlier post. I have revised the list. The latest is: