Since man began building things, there have been conflicts between the aesthetics of architecture versus the practicality of construction and operation. In difficult economic times or times of rapid innovation and change, these conflicts tend to escalate. For software architects, we're now experiencing both conditions. While the desire -- and in some cases the need -- to implement new systems based on the .Net Framework has never been greater, company management is demanding that decisions be made with an eye toward the budgetary bottom line. It's important for architects to stand firm on the platform of delivering business value and instead of delivering applications based solely on cost.
Let me be clear about the definition of value versus cost in the context of both the business and of the systems architecture. To the business, value is calculated not by considering only the cost to deliver the application itself, but by also considering the increase in revenues generated by the application and any associated decrease in cost to run the business. These cost savings may come from reduced labor or higher productivity, or they may be hard dollar savings from reduced infrastructure required to run the application. But architectural value is somewhat different. The value of architecture is measured by two key factors: longevity and implementation costs.
Architectural longevity refers to the organisation's ability to develop additional applications or entire systems without rethinking or re-implementing the underlying architecture. However, it's very easy for an architect to design a system that's reusable and extensible but that is impractical to implement because the costs are too high. Let's look at a key example of implementation cost that is a common discussion point for .Net architects -- using SOAP or using .Net Remoting.
SOAP versus .Net RemotingAny discussion regarding the use of SOAP as a protocol inevitably leads to a discussion of the "cost" of using XML, upon which it is based. The key attributes that make XML an ideal candidate for heterogeneous environments also make it an expensive protocol to implement. For example, two machines running the same operating system and the same processor type can exchange large record sets with the data stored in a compact binary format, but two machines with different operating systems and processors need a common format (XML) that describes the data in such a way that either can process it. Serialising the data from a binary format to a text file with XML tags that define its structure, sending the file to the second machine, and then deserialising the file into the second machine's native binary format is a much more expensive operation than exchanging data in binary format. Exchanging data in binary format takes more processor power on both machines, and the communications cost is increased based on the difference in the size of the payload, which is typically three to ten times larger when sending XML data. Most architects are willing to pay the processing and communication costs to allow two or more different machines to be able to pass data around in a common, digestible format. Moreover, the SOAP extensions currently being implemented by major software vendors like IBM, Microsoft, BEA, and Sun based on WS-I recommendations allow SOAP messages from different systems to be routed automatically and contain binary attachments usable on any platform. These extensions also allow the SOAP messages to be coordinated between different platforms, which allows for either synchronous transaction control or asynchronous transaction control, using compensating transactions. The cost equation is much less clear though when you consider a homogeneous environment. Several companies with whom I've worked are implementing .Net in a pure Microsoft environment. The obvious issue to consider in this environment is: "Why do I want to pay the costs associated with SOAP?" Although they certainly agree that the use of SOAP via HTTP over a standard IP port as an invocation protocol makes sense (versus the use of DCOM, which requires more infrastructure configuration to operate properly), they question the value of serialising the payload using SOAP versus using a binary formatter and using .Net Remoting. The latter option is faster, requires fewer processing cycles, and has a more efficient programming model for applications that require raising events and responding to them. However, using .Net Remoting means that you must develop your own internal architectural standards to ensure that all future systems will interoperate properly. In fact, a decision to use .Net Remoting as an internal standard almost guarantees that you'll have to implement your own versions of the WS-I routing and transactional standards that will certainly not be valid outside the walls of your own organisation. If your systems need to interoperate with non-Microsoft systems, then at a minimum you'll have to expose some of your underlying systems using SOAP standards, thereby requiring that you support both SOAP and binary formatting. So where are the savings? The bottom line is this: Absorbing the additional cost of implementing systems based on SOAP standards now will give you the ability to take advantage of current and future implementations of key extensions that you won't have to develop yourself. On the other hand, if you never foresee the need to "talk" to non-Microsoft systems, a pure .Net Remoting infrastructure will provide performance benefits that you simply can't achieve with a SOAP-based infrastructure.
For a weekly round-up of the enterprise IT news, sign up for the Enterpise newsletter.
Find out what's where in the new Tech Update with our Guided Tour.
Tell us what you think in the Enterprise Mailroom.
