Curtis Koppang's Radio Weblog

Tue, 13 Apr 2004 00:06:50 GMT

Not liking the interface, so I am going to take this to my own site. Link forthcoming.

Web Services Mindset

Sun, 26 Oct 2003 21:42:31 GMT

I am sitting in a PDC Pre-Conference session titled ".NET - The XML and Web Services Perspective" being given by Don Box, Tim Ewald and Martin Gudgin. Overall a pretty good summary of what the state of the technology is today. While I already have heard and written about much of this content already, it has been good at getting mind back into Web Services and Service Oriented Architectures (SOA); since I have been out of this world for a while. Kind of like going back to visit Hanibal Lector - only without the negative context.

The thing I have been trying to resolve in my mind is - what role do Web Services and SOA's have in the Enterprise, since this is the space I primarily play in. At the company I work for we run our business on three large third party applications. We spend allot of our resources extending and exchanging information around these products. Not to mention that each of these three products sits on a different platform. Which when I think of what Web Services are good at - seems like a perfect application of this technology. Only one problem, none of these products has anything resembling a Service Oriented Architecture. Rather they tend to do things like explain the database schema and expect you to update the database directly. This is about as tightly coupled as you can get! So why aren't we using Web Services?

I think that a major reason that we are not building more Service Oriented Architectures is simply that the skill set does not exist. I think you need several types of skills, all of which are missing at many of the Enterprises I have worked with - not just the one I am with now.

Architecture – Much of the design work is done by implementers who don't understand why XML/Schema or SOAP/WSDL) are better then CSV/FTP. There is a role on the project team called a Design Architect (DA) but they only tell you that you should use a technology in your implementation, but they don’t stay around long enough to actually help you with the implementation. In my world there is a role missing here – someone which actually delivers an implementation based upon a high level design.

Technology – There is a great deal of technology already embedded in the Enterprise which already accomplished much of what Web Services does for me; for instance FTP or MQSeries. We have a couple of applications where we use MQSeries; which is heading down the right road. But MQSeries (or queuing in general) is considered too complex by most programmers. IBM is partially to blame to for this, but so is my company. That is we both should be doing things to make using this technology easier by layering more application oriented services on the low level services.

Cross Platform – Does the expertise, technology or will exist on the other platforms? In my organization, it seems like much of the innovation around this stuff is happening only around Windows. Let me clarify, its not that all other platforms don’t have innovative technology around them; rather it seems that organizations tend to be able to only innovate on a single platform at any given time. They just don’t have individuals on multiple platforms with the motivation and/or skills to build these types of applications.

I think that over the next week Microsoft is going to try and address the Technology aspect of this problem. While I have some thoughts on how to address the other two issues (something for a future post); I hope to talk to people on whether they are experiencing similar issues.

Offshore Developement

Sat, 18 Oct 2003 03:01:40 GMT

Off to the Microsoft PDC. For anyone who might actually find my BLOG and know what the PDC is you might realize its a little early - the PDC starts on the October 19. Well you are correct, I will be playing golf in Palm Springs, CA with by brothers (early in the week) and some old Microsoft buddies (later in the week). That way I will be well rested for the next project we are going to tackle work.

This project has been designated as one where will use Satyam's services. This should prove a unique challenge to the development cycle, since as I understand their business model, they like to take parts (if not most) of the project offshore. I think there are two types of projects; those which you can afford to send offshore and those you can not. The projects that make good candidates for offshore work, in my opinion, are ones which are well defined and where you don't mind loosing the intellectual property you gain by doing the devleopment yourself. Since the only reason we are re-writing this system is because it is written using an unsupported technology, this seems like a pretty good case to let this go offshore. Unfortunately, for reasons before my ownership, it appears that we are going to use Satyam in a more T&E role.

Which gets me thinking a little more...is just knowing how the system is constructed considered intelectual property? What I mean is, once the system is delivered is it done? Certainly not. So if you did not write the system, how on do you plan on maintaining it? I mean certainly anyone can read the code, but is the code maintainable? Are you able to understand the intent of the person who wrote the system, so that as you update the system you aren't making things worse? What about the "not grown here" mentality you run into? It would be interesting to talk to folks who have moved projects offshore on how they solved these problems.

Fore!

Mon, 13 Oct 2003 22:14:36 GMT

Is it just me or do Computer Systems impact our lives in strange ways?

I just moved into a new house and wanted to give my money to the local cable company. I called three weeks before my closing date so as to get on the schedule for installation on a convenient day. The representative I talked to told me that should could not talk to me until the current residents first cancelled their service. ow I find it hard to believe that any business person would consider this a proper way to conduct business and that in fact the reason for this was that they were using a system which did not allow them to associate to names with the same address.

Not that I am any fan of the phone company, but they did not seem to have any problem with this scenario.

By the time the current resident cancelled service; I had to wait two weeks after moving in before getting service. No Internet (I am writing this on the Starbucks wireless network) and no TV.

I am so discusted that I went out and bought a DirectTV system which will be installed in only a week. That fixes the TV problem, now I just need to solve the connectivity problem (I can't afford to drink that much 'Bucks). DSL is really my only option, but the ADSL throughput sucks when I try to host XBOX games. I mean a man's gotta have hist priorities.

Sun, 28 Sep 2003 01:52:03 GMT

Today we rolled out an application to production. While not entirely remarkable in itself, it was quite an achievement. What should have been a trivial rollout (it only has one page) turned out to be a day long debugging session.

This application was written primarily by our most senior developer (in terms of length of time programming and pay grade) using Microsoft ASP.NET. While the application seems to perform the business functionality required, it does not do it in a robust way. What I mean is that there was not way for us to diagnose any issues once the application was deployed to production. While this may seem obvious to many; it is simply not something most developers I work with even consider. Even someone with as much experience as the individual I am referring to.

The solution to this problem is to first educate and/or mentor the programmers to understand that business features are not the only features which need to be built into an application. Then we need to give them the tools (e.g. components, infrastructure) to actually build a better mouse trap.

My current plan is to try the following:

Have weekly reviews of a chapter from Code Complete (by Steve McConnell). This book establishes a good foundation for writing code.
Introduce a reference architecture which people can use to startup a new project. This architecture will contain all the parts needed to begin development. We will use the Microsoft templates to accomplish this.
An example application which is based upon the reference architecture which fills in some of the blanks.
Make sure that every application is tested in an environment which at least resembles production. Taking something from a test server directly to production is just plain risky (if not foolish).