The true benefits of real-time analytics come to light after you've had a chance to enjoy first-hand how on-demand information makes management tasks so much easier. The real-time aspects of an operational environment are little understood and finding qualified experience to leverage real-time benefits is even harder. Most environments rely on batch processing, batch transfers, bulk data extracts, nightly loading, and then routine jobs for processing and handling it all. What if? What if the environment was real-time and the information you needed was just there.

It has been a long time since I wrote a blog entry and not due to lack of topics or lack of trying. It has been a very busy first half of the year with new customers and the 4.0 product release. In this entry I'd like to talk about viewing information through a different lens. That is, viewing information as a resource to be consumed by people rather than data that is processed and stored by computers. The reason for the topic is based on a lot of work that has gone into our latest 4.0 release and our passion for discovering and consuming vasts amount of information.

The ability to make decisions is as important a skill as any other for architects, designers, and engineers. It is essential for these technical leaders to have an air of decisiveness about them--a self-assured decisiveness. They have to be confident; and they have to have the ability to turn that confidence into strong decisions. Self-assured decisiveness is one of the more important soft-skills and does not refer to the ability to make quick or sometimes rash decisions.

I had an interesting conversation with a colleague today and the gist of the conversation hovered around the use of enterprise-class tools to ensure quality in code. The discussion was timely as the organization I was working with was debating techniques for ensuring quality coming out of the development teams. There were no clear answers in the discussion or winners in the on-going debate, but there was a consensus on the need to solve the problem.
 

You've developed your applications and exposed all the web services that you need. The system is now ready to deploy and you start to consider the transition steps. After a brief review you come to the conclusion that documentation might be waning in some areas but it's good enough for release. You now start the transition process ... when reality strikes. The transition team is asking a lot of questions, looking a little puzzled, and appearing somewhat daunted.

My last little coding exercise helped to reinforce the benefits of test driven development and it made me think about different approaches to creating web services. In the end, it all came back to the basic principles of test driven development where tests are written first and code is written to pass the tests.
 

It is interesting to watch how web services are developed and how they evolve. From observing recent development efforts, I was astonished to find that most developers still think along the lines of RPC, even seasoned development teams. For the most part, I observed that developers are looking for an API; a comfortable and easy route for building their component. They have specific, fine-grained requirements for input and output and they are rigid about the development patterns they use--patterns that are typical of the language or environment. Method calls and return statements.

Loose coupling is one of the hardest concepts to grasp, yet it is such a powerful concept. The introduction of Web services and Service Oriented Architectures touted the benefits of loose coupling, yet most of the tools on the market today discourage loosely coupled systems. Simply implementing or exposing interfaces as a Web service does not ensure that the applications are loosely coupled. In fact, it could be argued that most Web services used within the enterprise and for business-to-business integration are actually very tightly coupled.
 

There has been considerable debate in the web services world about whether new projects should take a start-from-code or start-from-WSDL approach. In the past, the start-from-WSDL approach has often won out. This was largely due to the maturity of the tools at the time and the experience of the community. However, with vastly improved tools and technologies, the start-from-WSDL approach may be an unnecessarily complex method whose time has past.

In the Beginning