Our group project is going well. It looks like we were able to successfully integrate all the pieces- web application, web services, and SAP. Everything seems to work well. Although we may need to make some minor changes, the main functionality seems to be in place.
   It is amazing how by using a relatively easy and efficient process several independent modules based on different technologies can be assembled into a single application.
   On Wednesday night I was planning to work from home on my part of the deliverable for the Milestone 3. However, after the class I learned that for some reason there was no signal in the telephone line at my house and therefore our DSL Internet was not working either.
   Because of that I had to stay late in the lab in order to complete my part of the deliverable and then drove back to Madison.
   Today I learned that our telephone line is being affected by the major AT&T outage which hopefully should be resolved by 10.00 a.m. on Friday, May 2. 

   I completed working on the term paper in rpML format. It was an interesting task that allowed me to get some experience in working with XML-based documents. 
   Our group project is moving forward. The web service is fully functional in exception with the SAP integration that has not been completed yet. There is also an issue with registering new customers that needs to be resolved.
   The basic application functionality has been developed. The Order screens, including Order review and Order submission still need some work as well as the overall user interface design.  

   I set up the web service for our group project.   
   Most of the methods are fully functional with the exception of GetProductList and ProcessOrder, which return dummy values because they are not integrated with SAP yet.  
   While using the convenient automatically generated web test form that can be invoked by typing the URL of an .asmx file, I noticed the regrettable limitation of that form. Unfortunately, it works only for simple data types and does not work for complex types like classes, etc.
   If a method accepts or returns a complex data type, the test form would show the following message: "The test form is only available for requests from the local machine." For simple data types, everything works fine though.
   I continue working on converting my term paper to rpML format. So far I completed approximately 30% of the work.

   Unfortunately, I was not able to attend the last class meeting because I was on a trip out of the city. Now I will need to review the slides and the textbook and complete Lab 4 from home.   
   On Monday, April 7, our team submitted the first deliverable of our group project (Project Design document). We are looking forward towards working on the second deliverable - service setup, which is due by Thursday, April 24.
   During the past week, I was very busy and did not have time for working on converting my term paper to rpML format. I hope that on the weekend of April 12-13 I should have some time to work the paper conversion. However, most likely, I will spend most of the weekend studying for the midterm examination for BUS ADM 814 (Business Intelligence Systems) which is scheduled for next Wednesday. 

I continue working on the Term Paper.
The more I read about ESB, the more I can see how controversial the topic is.  

People cannot agree on almost everything related to ESB.
For example, some people think that an ESB is not a product, but an architectural pattern.
Others, however, describe ESB as a coherent piece of infrastructure available for purchase through a number of vendors.

I believe that both notions are correct. ESB is definitely an architectural pattern with some distinctive features, but at the same time, it is a coherent piece of software and not just a composition of traditional middleware in a new packaging. 

I was also finally able to create a short homemade ESB definition based on the Dave Chappel's article: “ESB is a SOA-based Enterprise Application Integration Broker”. I think that the definition above gives a good idea of what ESB really does and what role it plays in the enterprise architecture.

   Surprisingly, most of the experts turned out to be not in favor of the ESB. Their thoughts were somewhat similar to those available in the interesting Steve Vinoski’s Blog entry.

   If I remember correctly they put the ESB in one row with the many failed attempts (like EJB, for example) to create a software "silver bullet" that will solve all the application integration problems.    As Steve notices in his blog "Many developers just want to write some code and plug it into a magical framework that transparently handles all the distribution, persistence, security, transactions, and reliability underneath. Chuckle. Underlying frameworks just grow and grow as they try to provide all this, and so they develop more bugs, more inconsistencies, more special cases, less flexibility, and less reliability as time goes on, not to mention foisting on the unwary the XML configuration hell..."

   Another their point was that the ESB is heavy utilized by software giants like IBM, Microsoft, Oracle, etc. trying to lure naive customers into a trap of an exclusive contract and make them heavily dependant on one particular vendor product.
   At first, it looked more like a  exaggeration to me. Just the following Monday, however,  I learned that Cape Clear, the ESB vendor that company where I work uses, was acquired by Workday. According to the article, Workday also mentioned that "the Cape Clear ESB will no longer be available as a standalone offering". The future of the ESB at my company has suddenly become uncertain.

   Another misconception mentioned in Steve's article is that "Large enterprises believe they can save themselves a lot of money and trouble if they can just get the whole enterprise to agree on a single integration architecture". In reality, states Steve, it never happens.

   Both Greater Wisconsin Software Symposium experts and Steve agree that in most of the cases dynamic languages and REST provide much better solution for lowering software development costs and achieving integration and extensibility than the ESB does.

   Well, this is definitely something to think about.

While working on the second reading assignment (John S. Webster, "Health Services," Computerworld, July 2005) I came across the familiar name of John Halamka - a controversial CIO of Boston-based CareGroup.

Apparently, John Halamka has recovered from the famous 2002 fiasco which is known to the public as "Beth Israel's Health-Care IT Disaster" and is considered to be one of the worst health-care IT disasters in the history of mankind. The detailed description of that case can be found in the excellent Harvard Business School study.

After reviewing the study, I came to conclusion that CareGroup’s senior IT management concentrated their efforts on the technology side of IT and paid too little attention to the actual IT management. The case clearly shows that even the latest and greatest IT solutions are not able to prevent system failure if they are not supplemented with proper management and governance.

It looks like Care Group IT, being very proud of the highest level of the implemented technology, did not have a solid disaster recovery plan or a reliable backup process. Security management, network planning, and change control processes did not seem to be of good quality either.

Now Halamka is very excited about “seamless data integration” and web services. In the Computerworld article he calls them “… the glue that you can use to create a virtual system”. However, he does not even mention the challenges of SOA Governance, which seems to be an alarming symptom to me. I hope that the Care Group IT avoids another disaster.