Category Archives: Ideas

Modeling Failure Scenarios

The inter-connectivity of the web as a hyper-linked pool of resources is spreading to applications as services are becoming more and more dependent on each other.

This new trend is requiring the architects to think more thoroughly about the fragility of the systems they design. My latest paper that was published on InfoQ deals with modeling the failures of dependent services upfront in the design phase/ This exercise lets the architects model and help implement systems that can deal with failure in a predictable manner.

Here is an excerpt from the paper

The increase in number of integrated systems in today’s enterprise solutions necessitates dealing with dependency and environment failures in a systematic way. By modeling dependency failures at the architecture stage, system response to failures can be communicated, tested and implemented reducing the business risk and cost.

In this paper, we will introduce system failure modeling. System failure modeling is a technique that helps anticipate dependency and environment failures and take pro-active action in the early architecture stage of a solution.

We will use a four step process to build failure models. Each step will gradually uncover the necessary information to create the failure models. At the end of the paper we will explore different tools and patterns available to architects that enable design and implementation of desired system responses to different failure modes.

You can click here to read the rest of the paper.

New Perspective

I was at QCon in San Francisco (qconsf.com) lats month a couple months ago. Coming from a Microsoft infused environment and lately being involved in Java world, it was a great experience. Seeing the open-source view of the software world was a real eye opener. I am not really at a point where I can say one view is better than the other, but there are quite a bit of differences in how software is designed and developed.

While I was there I had a couple of observations.

1. Java as a platform

I was part of a few discussions where there was growing distrust in Oracle in terms of keeping Java up to date and supplying the fresh features to the Java software community. There is a clear trend of creating specialized languages to solve certain problems on the Java stack. JRuby and Scala are two that are the two that come to mind right away but I think there will be quite a number of them in the coming years.

This may go many different ways but realistically I think this trend will follow and reach almost a biforcation at the JVM itself. I would not be surprised to see specialized implementations of the JVM in the coming years. Which begs the question, can the fragmentation of the JVM resemble the Linux distributions?

Frankly, I hope this does not become true as it would create yet another management nightmare for IT folks all around the world.

PS: Seeing that Oracle has been checking in some code that deals with commercial JVMs only strengthens the argument above.

2. Polyglot Programmers are increasing in number

The number of tools at the disposal of software architects are increasing in number. From NoSQL solutions to programming languages, there are a plethora of choices out there. This is especially true in the non Microsoft world (where most tooling and platforms are provided by Microsoft with some open-source library/framework that has been recently picking up).

This movement creates specialization opportunities for programmers. You can now be a Clojure guru or a memcached expert and create the best looking cocktail of technologies for the project at hand. The long term impact of this movement may have an impact on the average team size that is needed to support an operation. Although not a big concern for start ups, I think enterprises will be vary of this as it will require a larger number of people on staff to support these non-uniform solutions.

3. Agility is propagating

A couple of years ago, agile development was the buzz word. Although certain organizations and people confused it for doing a haphazard sloppy job, certain companies got it right. Now the trend is to move agility from just software creation to product creation, and in some cases organization management. More and more product companies are implementing agile in all aspects of their operations not just producing code. This is going to re-shape employee expectations in the coming years.

 

Cohesion in technical teams and your role as an architect

Coming to a software project later on, some things don’t tend to make sense. Why are there two services here instead of one? How come you are not using this way of message passing instead of that, why is your data format XML instead of JSON? Wait, you did not use a grid CSS layout?!

In my experience so far most of the answers to these questions are answered within the first 1,000 lines of code that you lay out in the beginning of the project whatever stack you might use you will run into similar (if not same) questions and you need to have the answers to such questions.

Lets face it, software design is as much artisan work as much as it is engineering.  Just like most paintings have a deeper story than what you can first spot in the beginning, most software architectures/designs have a story behind them. Unfortunately, as engineers by training (or scientists in my case) software crowd tends to get confrontational with black and white examples/dogmas when joining/taking over a project. Suggestions can be right or wrong, useful or futile, but if you can dodge most of the futile arguments and let people make the point for arguments that they strongly believe in the value of, why not do it?

But how do you make sure people argue something that is at least of some value to the project? Give them the best tool they can use: data.

In this case the data a software developer/architect needs usually falls into three categories:

  1. Data Flow -> where is the data coming from, why is it stored there, why are you moving it around and how is this achieved?
  2. Process Flow -> Why is the business process (even if you are writing a social photo sharing site there is a process flow don’t let the enterprisey word scare you) split over X number of nodes? How does this help you when considering scaling, response time and overall deployment plan?
  3. Team Dynamics -> Certain decisions are not always made in the light of sole technical sense. When there are two people on a project there is politics. Sometimes compromises need to be made to move projects forward. Best one can do in this case is to explain the thought process of what was considered, and why it was not chosen.

You might say, isn’t all this already there in code, database, emails? Yes it is there. Unfortunately for us though, no one goes back to hunt information. Part of your job, especially as an architect, is to make sure you collect/present/maintain this data. The reason present is bold is for (maybe not) obvious reasons; the quality of telling the story is just as important as the story itself.

Doesn’t sound exciting but this is the single best thing you can do if you want to have a cohesive technical team that works together despite differences in opinion.

 

Electronic Health Records

Here is a paper that I wrote a couple of months ago on EHRs and the state we are in currently. With the recent news in the media about EHRs, I think most of the issues are even more relevant today. Below is the first paragraph:

The United States population is one of the largest in the world with 300 million people and increasing at rate of 1%.1 A growing population of this size, however, also comes with its set of problems. One of the problems, maybe the most important, is health care and how it is provided and consumed in such a large country. One particular aspect of health care that makes it a special topic is its universality. No matter how healthy or sick, every single person in the population is part of this system either by receiving or providing health care, although the frequency and the amount of care will vary among different demographic groups. Unfortunately the cost of health care has been increasing over years and health cost per capita in the U.S. is highest in the world4. A direct result of high cost of health care is reflected in the decreased number of people getting the necessary medical treatment. According to a National Institute of Health (NIH) study, almost 8% of people who are in need of medical help cannot get it due to economic hardship.

You can read the rest of the article in PDF or Word format.