Applications grow more and more complex, while turnaround times get shorter and higher quality is expected.
Application boundaries are becoming blurred since data has to be available throughout the system in a seamless fashion. Data also has to be available in distributed environments, and as if that weren't enough, distributed systems are also expected to work when connections are down! How do you keep up with all of this?
The developer's world isn't as simple as it once was. When I got into professional business application development, the task was easy. We used COBOL in a DOS and Novell based environment. Even though this was a dramatic change from my C and Assembler based hobby programmer days, it was easy to adjust and within several months I was confident I knew everything there was to know about COBOL.
Later, I moved on to FoxPro for DOS, FoxPro for Windows, and eventually Visual FoxPro. The world was simple then. Even though FoxPro was (and still is) one of the richest feature and language environments I've ever worked in, one could still learn all the important aspects in a relatively short period of time. A programmer could learn one language and then never had to leave his “home stadium”. A few years ago, the only time I ever used a tool other than Visual FoxPro for development was when I used Rational Rose for my Object Models. Even that wasn't really an additional development tool , but more of an extended Diagram tool that was used sequentially before Visual FoxPro in the development cycle. To make a long story short: Life was monolithic!
From the interface to the data layer, the entire application could be built with a single development tool such as Visual Foxpro. In addition, the user ran the application in a monolithic fashion. She started her main application window, and that was considered “The App”. Data was basically trapped inside that program, and the only way to access that data from outside the app was a static export mechanism.
Things started to change as the Internet gained popularity. All of a sudden, it was no longer possible to do everything with one application. At the very least, one needed a web browser based interface. Sure, html files could be keyed in using Visual FoxPro's editor, but I soon realized that this wasn't the way to go. I began using a number of different HTML editors, including Microsoft's Visual InterDev and FrontPage, as well as some third party tools, such as HotMetalPro and HomeSite. By that time, SQL Server had gained more popularity, and we replaced the back end as well. Even though I never was a data guru, I couldn't ignore that change. Life was becoming more complicated and far less monolithic!
This was the time when applications also changed from the user's point of view. All of a sudden, the application wasn't synonymous with the application window anymore. In fact, there wasn't really even an application window since the browser was used as the interface layer. Obviously, distribution had also changed. Applications were now run on a server, disconnected from the user's web browser, making installation and maintenance a lot easier. However, as far as data availability was concerned, nothing had really changed, at least not for the better. The data was now trapped on the server, and it got a bit harder to write static export routines since there was no direct access to the user's hard drive. There were only two resolutions to this dilemma. Either a fat client application could be run on the client computer that queried binary data over Http from the server, or a standardized HTML page could be created that the client could parse and try to make sense of. An error prone scenario that was a recipe for disaster every time the HTML format had to be changed or enhanced.
It wasn't until XML came along that we could dynamically query data from the server in a standardized format, that was non-ambiguous, and wouldn't break client applications when the server had to be enhanced. A dramatic change that soon prooved to have the potential to revolutionize the way applications were written and used.
But not only distributed applications changed. “Regular” Windows applications could also now be architected dramatically differently. Rather than creating one big executable, the main application logic was moved into a COM based middle tier layer that accessed a data backend in a very flexible manner. The user of that construction was an interface that had very little logic and could be swapped and replaced with very little effort.
The downside of this architecture is that the developer is required to create applications that follow very strict guidelines. No rules can be bent and no shortcuts can be taken. Applications must be properly designed and architected before the programmer writes a single line of code. Otherwise all the advantages are lost, leaving the programmer with a “dirty” and hard to maintain architecture without any gains. This is a hurdle that many developers are still struggling to make.
We now have arrived at a stage where Windows 2000 has just been released, and Windows DNA 2000 is now widely available. Many potential clients have not yet upgraded, but considering that it will take most developers some time to familiarize themselves with this new way of doing things (in additon to the actual development time), this seems to be the perfect time to for software developers to move full speed ahead with Windows DNA 2000 development.
Windows DNA development is not the final destination, but is certainly a giant leap forward in the evolution of software design. We have moved into a scenario where the borders between Windows and Web applications have become blurred, , if not totally vanished. But those are not the only boundaries to break down. Every desktop has changed from a workstation that runs a number of unrelated applications with their own sets of data and rules, to a system of business components that make data and business logic available throughout the system. Business events (see my article about COM+ Events in this issue) turn components from a system that provides data only on request, to a service oriented model, that allows for seamless and very flexible real time integration on demand.
We have finally rrived in a world where software is modeled according to the business, and not vice versa. A world where software does not lag 12 to 18 months behind business needs. A business world that is not restricted by data trapped in single applications. A business world where modern software makes the difference between the failure and success of a company. The Windows DNA Developer makes all of this possible. I'm excited!
