Enterprise Architecture

Instrumentation Wrapper for .NET Distributed Applications

Mike McIntyre [MVP Visual Basic] — Thu, 17 Feb 2005 21:34:00 GMT

Distributed enterprise applications aggregate the power of mutiple servers and multiple software applications to collaboratively run a single computational task in a transparent and coherent way, so that they appear as a single, centralized system.

It is the 'distributed' aspect of the distributed application architecture that introduces the need for an instrumentation framework that can measure and control the distributed application accross its logical and physical boundaries.

I have been designing and developing instrumentation frameworks (wrappers) for distributed applications on various platforms for over 10 years. I have tried commercial products but for the most part the only way I could get good results was by 'rolling my own'.

The past two days I have been experimenting with the Enterprise Instrumentation Framework (EIF) a free downloadable instrumentation framework from Microsoft.

If you need to add an instrumentation framework to a distributed application I recommend you download Microsoft's Enterprise Instrumentation Framework.

It is good block of modifiable code, suitable for learning what an instrumentation framework is and to modify and deploy as an instrumentation wrapper around a .NET distributed application.

Two New Microsoft Resources for Enterprise Development

Mike McIntyre [MVP Visual Basic] — Tue, 08 Feb 2005 10:39:00 GMT

First, the Connected Systems Business helps you see how Microsoft's hardware, software, patterns, and practices works to day and where its going in the future.

Second, the Patterns and Practices Enterprise Library consolidates and updates seven of the application blocks Microsoft has produced.

The Connected Systems Kit

The Connected Systems Kit is a collection of sample applications, presentations, white papers and videos that illustrate how to implement connected systems and service-oriented architectures using current technologies.

Start here: Connected Systems

Patterns & Practices Enterprise Library

The patterns & practices Enterprise Library is a collection of application blocks designed to assist enterprise developers with common enterprise development challenges and help them build high-quality solutions with less effort. Developers are able to use the blocks as is, extend them to meet new requirements by plugging in their own code, or use them as the basis for more-complex solutions. Enterprise Library is available as a free download at the patterns & practices Web site at:

Patterns & Practices

.NET - The Ball of Mud Killer

Mike McIntyre [MVP Visual Basic] — Thu, 27 Jan 2005 17:33:00 GMT

Big Ball of Mud is an term that describes a system or computer program that has no real distinguishable architecture and is choking to death from all the mud that has been thrown on it to keep it alive.

Brian Foote and Joseph Yoder popularized the Big Ball of Mud term in their Big Ball of Mud paper. That paper defines the term as:

"A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spagetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems."

Big Ball of Mud systems are developed over a period of time, by different individuals with different skill levels doing what they think is best at the time.

Foote and Yoder do not universally condemn Big Ball of Mud programming. They point out that this pattern is most prevalent because it works — at least for the moment. However, as they become caked with mud programs of this pattern become maintenance nightmares producing less and less reliable results.

Overtime if left unchecked, the mud will eventually choke the system to death.

Often the best thing to do when you encounter a Big Ball of Mud system is to learn what it accomplishes and from that start drafting requirements for a new well architected system.

By the way, times when technology shifts (procedural to OO programming, client-server to web-based, file-based to database, the introduction of the internet etc.) can provide good reasons to kill off the Big Ball of Mud system and move on. Often Big Ball of Mud systems can not effectively take on the new technology which introduces the opportunity to kill the old system and build a new well architected system.

Which brings us back to the .NET Framework. The .NET Framework is a technology shift - just ask any VB Classic programmer.

It you are responsible for a Big Ball of Mud system take another look at the .NET Framework.

It may be the road to your salvation.