Monday, December 20, 2010

Naturally Yours,

The stars are getting aligned for Natural User Interface (NUI) technologies, with widespread adoptions of touch phones and pads, and recent advancements in consumer technologies such as Xbox Kinect. Consumers have progressed from ‘liking’ to ‘expecting’ natural multi-touch interface. Many technologies are already creative waves.  In L&T Infotech, our Tech office experimented with Microsoft Surface and I was amazed to see the possibilities. Touch IT

I suspect that we will see explosion of application of these technologies everywhere in coming years…!  Consumer electronics industry such as Gaming, Phones, and computers will naturally be far ahead, however, I wonder where we will use this in Insurance industry.
I bet it will be for marketing splash and customer acquisition. I can see consumers leaning on the interactive tables and playing with Geco to understand different parts of policies OR interacting with cute Progressive lady to name their price. Who says buying insurance cannot be fun?


Share/Bookmark

- Amit Unde

Thursday, September 2, 2010

Is it End of Zachman ?

It's very sad the way things turned out for John Zachman's associations. Just came across an excellent post by Gartner's Philip Allega on this topic - http://blogs.gartner.com/philip-allega/2010/09/01/john-zachman-is-dead-long-live-john-zachman/

One would have expected further research from such elites, rather than just attempts of commercialization of the framework. Really, not much has been added to the framework, since, it is published in 1980s... Though there is lot of value in the thoughts that are behind the framework, IMHO, the use of framework itself is quite hyped.
In comparison, other established EA frameworks ( and methodologies) like TOGAF and even the new upcoming like EACOE are quite useful. May be they will continue Zachman's legacy.. but without his name !
Looks like he wants it that way.

Monday, February 1, 2010

Agile adaptation of Architecture Evaluation Methodologies

I discussed some of the architecture evaluation methods in my previous post.  In short, the idea is - Rather than just using a checklist for technical evaluation, we should test drive each functional scenario against architectural decisions and judge the impact on quality attributes (utility tree) and evaluate the architecture. Such a review will be more specific to the project and hence, more beneficial.
Many accept the advantages of these methods, however, often criticize these methods for their overhead. I think, these methodologies can certainly be adapted for agile use. We do not have to stick to the the elaborate process that SEI has recommended, but instead, we should adapt it for our use by sticking only to its principles. In fact, in my experience, these methodologies are more beneficial if we use them in conjunction with agile development methodologies.

Why Architecture evaluation is important for Agile methodologies?
In Agile world, the application functionality is to be built in agile way, with constant visibility to business, and frequent changes to the features. However, the same is not the case for its architecture. If the architecture is allowed to evolve with changing requirements, it causes frequent rework, constant re-factoring and in fact, it counters the ‘Agile’ response. It makes sense to spend upfront time on architecture evaluation and ensure that it is flexible to accommodate the future changes.

What are the steps in evaluation?
I assume that you have background of standard evaluation methods such as ATAM / CBAM. If not, refer my last post. Though SEI has defined a very elaborate process, I think, only the following are critical steps –
Step 1 – Prioritize functional scenarios along with all stakeholders and identify architectural approaches and alternatives
Step 2 – Generate Quality Attribute Utility Tree and specify Stimuli – Response for each scenario
Step 3 – Analyze architecture approaches and identify all possible
a)      Risks,
b)      Non-Risks,
c)       Sensitivity Points ( interdependencies) and
d)      Trade-Off Points.
Step 4 – Quantify the Benefits of different architectural strategies and corresponding Cost and Schedule implications
Step 5 – Calculate desirability (benefit divided by cost) and Rank the alternatives.
Step 6 – Make decisions and document

What about the overhead of evaluation? How can it be done in Agile Way?
To make these methods more agile, use following techniques -

  1. Evaluate on Sampling basis –Short-list only the unique and critical scenarios that are likely to change.
  2. Create the artifacts such as Utility Tree as part of Architecture development process and not just for evaluation. The act of creating the utility tree will improve the thought process while defining the architecture.
  3. Evaluate everyday as soon as you discuss the scenarios in the war room. All the stakeholders are present in the war room. This avoids extensive planning, presentations, and elaborate evaluation exercises.
  4. During the evaluation, apply the utility tree to each scenario and evaluate the Sensitivity Points, Risks /Non-risks points, and Trade-off points. In case of alternative solutions, estimate Cost and perform Cost-Benefit analysis.
  5. Evaluate not only for the defined scenarios, but also for the possible changes. Get the ‘change’ scenarios from the business to evaluate the impact of changes. The architecture should be flexible to accommodate such changes.
Share/Bookmark

- Amit Unde

Wednesday, January 13, 2010

Test Drive your Architectures for effective evaluations

Are you one of those sitting in ivory towers of Enterprise Architecture Group, tasked with responsibility of evaluating project architectures and ensuring IT Governance? If you have done few reviews before, you would know that it is highly subjective process that depends largely on the evaluators’ technical skills, functional/environmental knowledge, authority structure, and other political forces. The evaluators who are parachuted into the project group for reviews are especially handicapped due to lack of knowledge of functional requirements, and often only concentrate on ‘technology’ implementation reviews. Hence, most of the reviews remain superficial and only partially beneficial.

So how exactly should you evaluate the architectures? 
I would say do what you do when you buy a car. Test Drive! You will only know the car’s performance when you actually drive it and feel it, and not just by reading specifications or by asking questions. Similarly, to evaluate the architecture, apply it to the specific functional scenarios and measure the quality attributes.
Carnegie Mellon Institute (SEI) has developed the architecture evaluation methodologies on the same principle. The most known methods are –


This methodology analyzes how well the software architecture satisfies the quality attributes (e.g. scalability, modifiability, performance etc), by applying the architecture to short-listed functional scenarios. It prescribes developing a quality attribute utility tree, and analyzing it for each scenario and alternative architecture approaches. For each scenario, the method prescribes identifying the following –
a)    Sensitivity points – a collection of components that are critical for achieving a quality attribute,
b)    Trade-off points – a sensitivity point that affects multiple quality attributes, typically trades one off for the other,
c)    Risks – something that inhibits the system from achieving its quality goal (this also includes the decisions that are not taken),
d)    Non-risks – something that is done right (and should not be changed)



CBAM begins where ATAM leaves off. It prescribes analyzing the cost, benefits and schedule implications as well for architectural approaches before making the final decisions.


This is more of a design review than architecture review, but uses the same principle of applying design to scenarios, and even writing a pseudo code to evaluate different parts of design.

The SEI has documented a very formal step by step process for all these methods. One way that may be counter productive as people tend to focus on activities, rather than the principles behind these methods. There is a great scope to tailor these methods to suit your organization, and conduct such evaluation in agile way.

More on this topic later…

Share/Bookmark

- Amit Unde

Tuesday, January 12, 2010

Clouds of Insecurity

Today, Google disclosed sophisticated attacks on its infrastructure from China and its response to it. While Google's response is a welcome move, it raises doubts in my mind about the safely of the cloud. This is not isolated instance. Recently, another public Cloud vendor, Salesforce.com, was crashed down for considerable time and raised many questions about cloud's credibility.

What makes these 'Public' clouds more insecure?
Not its infrastructure as much as its popularity ! My organization's infrastructure is not likely to be secure as Google's, however, it is not likely to be on radar of hackers either. The hackers may spend days and nights to bring google down, will they pay same attention to my organization? Probably not.
The 'Cloud' may bring-in efficiency, but it will be a trade off with the increased risk of data loss and security, at least in the near future. The benefits of cloud should be carefully weighed against the risks before committing to the cloud. Recently, Gartner published a report for Assessing the Security Risks of Cloud Computing. Click here to read seven of the specific security issues Gartner says customers should raise with vendors before selecting a cloud vendor.

Share/Bookmark

Saturday, January 9, 2010

Business Architecture – Is it IT’s intrusion into Business?

OMG’s SOA Consortium working group recently published a paper on their perspective of Business Architecture.  The paper is clearly by the IT Practitioners.  The way they define Business Architecture is as follows –
We define business architecture as the formal representation and active management of business design. Expanding this definition, business architecture is a formalized collection of practices, information and tools for business professionals to assess and implement business design and business change.
The paper advocates the active management of business design, with the same focus as that of IT.  Though it sounds good on paper, is it really practical? -  Especially when the fact is Enterprise Architecture is driven by IT. Will the social and power structure present in Today’s organization allow this?


 No doubt that we need a clear understanding and formal representation of business design, however, the comprehensiveness should be limited to suit the need, which is typically an input to IT (and not management of business).  Also, the involvement of business in driving the IT solution is critical, however, the involvement should be periodic, although frequent, and every attempt should be made to keep the overhead on business  as minimum as possible.  Attempting active management of business may be considered as unnecessary intrusion of IT into business and often, it is counter-productive. Instead, a process for periodic review of business models and refresh should be institutionalized.  The EA-IT team should, however, do the active management of IT portfolio and ensure alignment of IT investments with business goals through active governance structure.

Having said this, the paper does provide some useful information and examples of artifacts. It will be good if OMG standardizes the business architecture models and encourage tool vendors to support it. The Enterprise Business Motivation Model (EBMM) will be a great start.


Share/Bookmark

Monday, January 4, 2010

A fresh look at 2010

One of my colleagues (David Roy), sent me a list of questions related to my previous post, that can guide 2009 Review and 2010 Goal settings. He got these questions from the Newsletter by David Allen (Author of Getting Things Done).

Completing and remembering 2009


Review the list of all completed projects

What was your biggest triumph in 2009?

What was the smartest decision you made in 2009?

What one word best sums up and describes your 2009 experience?

What was the greatest lesson you learned in 2009?

What was the most loving service you performed in 2009?

What is your biggest piece of unfinished business in 2009?

What are you most happy about completing in 2009?

Who were the three people that had the greatest impact on your life in 2009?

What was the biggest risk you took in 2009?

What was the biggest surprise in 2009?

What important relationship improved the most in 2009?

What compliment would you liked to have received in 2009?

What compliment would you liked to have given in 2009?

What else do you need to do or say to be complete with 2009?

Creating the new year

What would you like to be your biggest triumph in 2010?

What advice would you like to give yourself in 2010?

What is the major effort you are planning to improve your financial results in 2010?

What would you be most happy about completing in 2010?

What major indulgence are you willing to experience in 2010?

What would you most like to change about yourself in 2010?

What are you looking forward to learning in 2010?

What do you think your biggest risk will be in 2010?

What about your work, are you most committed to changing and improving in 2010?

What is one as yet undeveloped talent you are willing to explore in 2010?

What brings you the most joy and how are you going to do or have more of that in 2010?

Who or what, other than yourself, are you most committed to loving and serving in 2010?

What one word would you like to have as your theme in 2010?

For more on this subject, visit David Allen's web site - http://www.davidco.com/

Share/Bookmark