The glue for business growth

The "party" of the nineties (90's) has become the "working party" of the noughties (00's) and the toolset of choice is BizTalk.  Participants in the BizTalk community are committed to making this vision of business-to-business communication and interoperability a reality.  BizTalk is the great enabler; it is the Swiss Army knife for Internet business eCommerce.  It brings the promise and power of XML to businesses and to their existing and legacy systems.

We have all heard of B2B (business-to-business) and B2C (business-to-consumer), but unless your company has very deep pockets and a sizeable team of highly skilled developers, how are you going to build that killer application for communicating with your customers and partners?   BizTalk brings the tools and the platform you need to take your business to achieve these immense goals and to deliver the benefits.

Business building blocks

BizTalk Server 2000 is one of the many Windows DNA 2000 building blocks, including Microsoft Windows 2000, Visual Studio®, Host Integration Server 2000, Application Center 2000, Commerce Server 2000, and SQL Server 2000.

Windows DNA 2000 encompasses the next generation infrastructure for building Web applications and promises even faster and easier development, greater interoperability with other Web applications and legacy systems, and simplified deployment and management of Windows DNA solutions. With extensive support for message-oriented interoperability and pervasive, integral XML support, the Windows DNA 2000 family is the ideal solution for managing the transition from today's Web sites to tomorrow's Web services.

Reducing the complexity of building systems

Typically, large companies have many specialized systems, including a data warehouse, processing software, receivables management, document dispatch and document or purchases receipt, document management systems, payments systems, call centers, accounts software and client registers to list only a few systems.

Usually the middleware has been built in a loose confederation of DLLs, competing object models and a mish-mash of ad-hoc solutions.  The result could look remarkably like this:

The costs associated to an ad-hoc growth of applications and middleware to tie these disparate systems together could include:

• duplication of effort (all the developers on all the projects will invest effort into maintaining or updating their part of the system to accommodate any change)
• an increasing amount of development time is spent supporting the systems as the sheer number, complexity and interdependencies have grown
• the addition of a new application could cause the group of application to become unstable
• changing a key component (such as a database) or even the renaming of a component can cause instability (or worse!)

A more suitable solution could be envisioned as this, where all applications request the data they need by calling a middleware set of applications:

In this design, the applications are not dependant, none of the talk directly to any of the others.  We have de-coupled the applications from the middleware.  Now applications can be upgraded, renamed and changed without causing instability.

However, there is still room for improvement.  Experience shows that the middleware itself is usually tied closely to the data source.  This means that if a DLL was expecting the SQL Server database to have the name "SQL1" and it was changed after a merger to "COMPANYNAME_SQL1" then the DLL would stop working!

This leads us to the question of what that middleware should be and what it's relationship to the data sources could be.  Traditionally the middleware is a set of components, and it looks like this:

In this scenario, the data sources (shown here simplistically as the file system, files, a database such as SQL Server and mainframe or legacy systems) are accessed via components (most likely DLLs) which are held on the MTS (or 'Microsoft Transaction Server').  While this is a good approach to building middleware, it doesn't really improve the long-term multi-application scenario.  Even if a tremendous amount of work, process, rules and learning about topics like "design patterns" have been invested in (in order to ensure that the team builds a suitable and extensible middleware) the problem of changing data sources remains.  Tightly coupled systems do not usually stand the test of time.

Loose coupling allows flexibility

Let's focus a bit more on the problem of growth within large and complex organizations.  When you replace or upgrade your database, does it cause instability in your existing systems? When rolling out a new application, do you have to test it for compliance with all your existing systems?  What would happen to a closed and tightly designed set of applications if one of them was replaced or completely outsourced to a company which knew nothing of your internal software dependencies?  Will some of those applications cease to work?

Really, it is a sad state of affairs when we feel hamstrung because of software.  Seriously, shouldn't our business systems access data and not be concerned about where that data is being stored or hosted, if it changes or is renamed?

Highly inter-dependant applications, or even worse, applications which directly access their data stores are a expensive cost to a business over the course of years and are essentially a liability.

So, how can we achieve this nirvana of being purely data centric?  Where a system simply receives the data it needs without caring about the protocols, the platform or the system housing the data.  Firstly, one step towards lowering the long term cost of supporting systems, is to separate the middleware from both the applications and the data sources, perhaps in this way:

Let's take a look at some of the ideal features of a middleware which can bring:

• lower maintenance cost for the inevitable business changes
• it is cheaper to build applications which consume data without concerning themselves about the location of the data
• easier to manage/redesign the data sources supplying data to the applications within the organization, data sources can be renamed, can change location and can be upgraded

I once heard a person describe an ERP system as "an opportunity to redesign the corporate business processes".  I think not.  In fact, I would prefer to see software reflect the real business needs, rather than have to redesign the business to mould to the software.

Publish and subscribe

If applications were designed to subscribe to data (independent of the source of that data) and data sources were to publish data (independent of the knowledge of whom the subscriber is), then we could design flexible, inexpensive and easily manageable software.

Software which consumes data regardless of the data source.  Data, which is not moulded and constrained by the container it happens to be inside at the time. Data which is free to be consumed in new and exciting ways - without redesigning your existing investments!

BizTalk is just such an environment.  Using BizTalk's provided publish and subscribe tools, you could publish all types of data (client listings, employees and so on) and maintain the integrity of the data throughout.  Let's take a look at (simplistically) what that could look like.

If we look at building software as an architecture, we will need several components including:

• data sources (possibly including mainframe/host/legacy access)
• business rules, workflow and document management services
• presentation services or applications
• security and other related services like networks and transport protocols

One way of looking at how these services interact as an architecture, is as follows:

Considering all these blocks and the enormous amount of messaging which is required between these components, the green areas indicate the aspects of an architecture which can be provided by Windows DNA and the appropriate BizTalk services, in order to simplify your development solutions.  This approach reduces your complexity enormously and enables your development team to focus more narrowly on the brown areas and creating components for those areas.

In addition to simplifying business processes, BizTalk therefore also provides an opportunity to streamline, simplify and save costs in your internal IT processes.  Many existing internal architectures which IT teams build look rather like something this:

With many applications communicating to each other directly and communicating to data sources directly (via ODBC for example), the tight coupling of these systems presents a cost to the business if a redesign or change is required.  A more flexible and lower cost overall solution is presented below.

Windows DNA 2000

Let's dig in deeper than before and understand the core applications and architecture which underpins the BizTalk Server toolset.  The first set of components to understand is Windows DNA (or 'Windows Distributed internetworking Architecture').

Windows DNA provide the common tools and architecture for your organizations technical needs.  It endeavours also to provide the complete set of tools and system services to simplify your development teams needs.

By providing out-of-the-box access to host/mainframe data sources (Host Integration Server), transaction queuing (MTS), data access (ODBC), xml support, presentation, messaging (Microsoft Exchange), security (PKI) and many other services and tools, Windows DNA provides many reusable tools to simplify your architecture.  The overall picture looks like this:

But in the murky and dynamic world of eCommerce, Windows DNA 2000 must bring a host of new and important services and tools to bear and as you may have suspected, the open standard of XML underpins them all.  Here is a snapshot of what you can expect to use in your future projects!  On the left is a list of components you can use and the the corresponding benefit this component brings is mapped on the right.  Underpinning it all is the XML messaging infrastructure.

By attempting to ensure that most of the services required to build commercial applications is provided, Windows DNA removes these issues from the IT department manager's list of concerns.

BizTalk therefore is rightly seen as a part of the DNA architecture, as it takes care of the data conversion, mapping and plumbing needed for applications to exchange data with other internal or external participants.