Editor's Note - March 2002

Article
02/09/2009

.Net, the Real World, and IT

This is Part 3 of a three-part series of notes about .NET. Part 1 gives an overview of .NET from the IT perspective, along with a definition of .NET (and my take on that definition). Part 2 described an IT-centric view of the .NET components, focusing particularly on the .NET server products. This part describes a number of real-world IT apps and opportunities to implement .NET.

Think about the three components in this article's title. The prevailing wisdom is that their intersection is the null set, right? In fact, there are those who would say that about any two of the three. I can be as cynical as anyone else — folks say cynicism is my Olympic-level sport; nonetheless, I think .NET and IT can work a great partnership with the real world. I want to offer some suggestions and examples below.

I'm not suggesting this is an easy partnership; the real world has all sorts of sharp edges and nasty corners. I think it can be a cost-effective partnership, however.

The following suggestions and examples are based on real-word scenarios I've encountered in my years of consulting; in a few cases, I've disguised actual companies. Some of these are enterprise systems, with others looking at smaller companies or departmental solutions. Some are Internet based, but many use only an intranet. There is no code here, nor instant solutions; my goal is to stimulate thinking around how you might use .NET to help your company.

Internet.NET

Previously in This Column…

For starters, in a sidebar to Part 1, I described two .NET systems that companies have already built.

Inventory and Supply Chain

Here's an example involving parts lists and distribution/sales. This example would work just as well with auto parts, or kid's clothes, or most other "goods" industries, but let's say I manufacture heavy trucks at Steve's Truck Yard (STY — I was looking at my desk when I came up with this acronym). Dealers have franchises to sell my trucks, and I get parts from about 100 suppliers. I have a good inventory system, but getting supplies just-in-time from my suppliers is painful. It's a manual process to "exchange data" with the suppliers. If you've been here — I think we've all been here — you know that "exchange" is a nice way to say "reenter."

I can increase profits if I cut both inventory costs and stock-out situations; any time lag — i.e., doing everything by hand, or by formula — will cost us money and/or sales.

Likely approaches? I could do nothing; no cost, but no benefit either, and I'm in trouble if I lose the one employee who understands how it all works. I could build a connector to my suppliers using EDI and/or a lot of custom and one-off code. Or I could build that same connector quickly using BizTalk 2002 Server (which can also work with existing EDI solutions).

As noted in Part 2, BizTalk is terrific at helping disparate systems talk to each other. The harder part may involve people and not technology, but I have some ideas here too that I'll detail in the next column. (Does that make it Part 4 of this three-part series?)

First, much of the work may already be done. There are some 300 adapters/connectors linking BizTalk to other systems and software: Arriba and Commerce One, Oracle and SAP, Excel and Word, Java and EDI, CORBA and CICS and COM, oh, my, and hundreds of others. Why reinvent the wheel? The variety of third-party stuff out there is amazing. Second, some of my suppliers may already be looking at or even using BizTalk Accelerator for Suppliers; if so, my work, while not done, is lessened even further. Third, I could write an application adapter using one of BizTalk's component interfaces to feed data directly to and from my current applications.

It happens that STY is running a well-known inventory management system at the warehouse, so I can license BizTalk plus a third-party adapter for my end. This works even though that system uses not SQL Server but some database from a company down in California. And if some suppliers are running EDI or have an XML-compliant interface (I can dream, can't I?), connecting to them will be pretty easy.

There are three hard parts in this scenario: finding suppliers capable of and willing to exchange data and requests via the 'Net, connecting the various data sources, and writing the logic that actually does something with the data, such as triggering a reorder request when inventory reaches a certain level. The first (data sharing) is becoming easier and is even commonplace in some industries. BizTalk and its adapters take the hassle out of the second (communication). The third part (business logic), of course, is still hard.

But corporate IT should be pretty familiar with the needed business logic; it's the bread-and-butter of our systems. I do not mean to suggest that this problem is trivial, but I do believe it's manageable and has a relatively short payback time.

This isn't just about manufacturing. Think about seasonal goods, such as snow tires, or air conditioners, or lawn tractors. Whether you sell them or manufacture them, you must be acutely attuned to seasonal and market variations; the company that gets it right each year will be ahead of those companies that go with the average flow. And you've got to ship those goods; how many container-loads of your product will you ship Thursday? That's even more critical when you product is food; what's the value of having your systems talking to those of your long-haul truck dispatchers?

How often has business gotten it wrong?

We don't get many chances to be business heroes; jump on chances when they arise.

Intranet.NET

Desperately Seeking Services

It's easy to think of Commerce Server simply as an Internet commerce (i.e., money-changes-hands-in-a-transaction) tool. In fact, we make it easy to see it this way — I presume because that's the reason most people license it. However, I think there are a few other ways it can benefit a business without ever touching the Internet.

First, Commerce can provide an easy way to register and track users on your site. If you have some reason users have to log in, such as a shareholder-only area for a public company, you can use Commerce to handle registration and access. Is it a bit heavy for that rather simple task? Consider the time you can save, especially if you want to log where users go so you can build a site better suited to their needs. You can also profile your users and target content directly to them. You can push almost all of the day-to-day campaign work out to relatively nontechnical users once IT sets up the underlying program.

(Personally, I hate sites that for reasons I can't fathom make me log in, so I urge you to be sure the benefits to your user outweigh the off-putting nature of such logins. On the other hand, I'm happy to log in to, say, The New York Times in order to read the paper on line; the benefit to me in this case is obvious. And targeting should offer advantages to the user, please, not just popup ads! Just my opinion, of course.)

Second, Commerce offers an easy way to manage direct-mail campaigns in house, using a great workflow engine called the pipeline. Commerce comes with a DM pipeline you can easily set up to fit your particular needs.

Third, it's easy to create a product catalog using Commerce. This is valuable even if you don't sell a bunch of parts over the Internet. What about parts used internally? (Think back to the STY example above; having worked on a tracking system for a company not unlike STY, I know how incredibly many parts are involved.) How many forms does your company use, and how often can end-users find the right one?

Finally, it's easy to integrate Commerce with your ERP system; you don't need to create more data islands.

Commerce Server integrates naturally in the .NET world with COM+ services and with Application Center, BizTalk, Host Integration, and SQL Servers.

Internal_Or_External_It_Makes_No_Difference.NET

Data Sharing (or, BizTalk as Babel Fish)

The late Douglas Adams envisioned the Babel fish, in The Hitchhiker's Guide to the Galaxy, as a universal translator. BizTalk Server can play a similar role in the data center.

It's hard to find a Babel fish, but if you do happen across one, just put it in your ear and it will start working. BizTalk's easier to find, if slightly harder to use. It's sure easier than hand-coding data translators, however (I made a good living a dozen years ago doing that). It's highly resilient with respect to changes in data schemas; obviously, major conceptual schema changes may hit you, but the XML architecture allows you to glide over most of the day-to-day tinkering that inevitably goes on.

I can't say enough about BizTalk Server as a bridge among all those islands of data in our systems. Let me just suggest some possibilities that might help a business:

Build document maps that allow apps and business partners who use different document definitions to communicate without adopting a common database. This also works for internal groups using different systems and unable to come to agreement on a common worldview… even though we know this standoff never really happens, right? Most importantly, these BizTalk-based systems are easily modified when schemas (yours or theirs) change. As I noted last time out, BizTalk works well with and can supplement an existing EDI solution.
Transfer data among systems during a merger or acquisition. IT only has the second-hardest job in M&A; merging the cultures is even harder than merging the data. Still, data migration is quite painful. You can use BizTalk to run parallel systems as you work through changeovers, or to consolidate data while still providing service to at least some of the systems of the taken-over company.
Manage business processes , even those that span days or weeks but must result in true (ACID) transactions. BizTalk even has connectors for MQ Series and CICS.

A four-month-trial version of BizTalk Server 2002 is available on line. You have to register, but you get something besides popup ads for doing so.

Programming.NET

Visual Studio .NET is not just the .NET version of our programming environment; it contains some truly neat tools for creating web services. It also contains the .NET framework as a unifying platform for any of the .NET languages, from VB to C# to Java to COBOL. (Click here for some thoughts about VB.NET and C#.) It's the way to write any custom code needed for .NET — or pretty much anything else. VS also supports BizTalk with some specialized tools, particularly around business processes.

Snacks.NET

The folks at TechNet have been bugging me to mention this internal app. Microsoft has the reputation — deserved — for having meetings with food supplied. Lots of food. More food than attendees, to ensure everyone gets fed. And thus — leftovers.

Lots of leftovers. And they often go uneaten even by our programmers-cum-scavengers, because no one knows the leftovers are in one of our kitchens.

Until now.

Some of our documentation folks decided that they could do more than write about .NET. In just a few hours, they built a web service called Snax that tracks all leftovers. You can register food sightings, get e-mail alerts when there's food available in your building, or check the site at any time to see what's available. (As I write this, the site shows donuts and three different collections of Chinese food. This probably confirms whatever prejudices you already have about the tastes of Microsoft folks, although I'd argue that this is programmer-food anywhere.)

Okay, here's the real point — they built this extremely rapidly. And most of the functions/services were reached with only a few lines of code. Here's what the developer wrote to me (with a bit of Micro-speak edited out):

We had a meeting a few months ago about the RADness of Visual Basic. The Program Manager said that VB programmers only wanted to write two lines of code to get something done. So I analyzed our application against this goal. The Web application (the Snax web site) did pretty well in being able to meet that goal. Even on the Web service most methods have 10 or fewer lines of code.

The Program Manager may have been joking about VB developers and two lines of code, but as an IT guy that's a terrific standard. Keep it simple, avoid the fancy/cute stuff, and you have a fighting chance of maintaining the code without needing lifetime job security for the programmer who wrote it. I'll try to post the Snax code by the time this article is published so you can see for yourself.

And yes, there's a small kitchen on pretty much every floor here, complete with the fabled free sodas. Through these kitchens, you can follow the graying of Microsoft. When I started, Jolt Cola was big; nowadays, it's Diet Coke/Pepsi without caffeine.

Conclusion

Would you believe this three-part series — the three longest Editor's Notes I've written — started out as a sidebar to another Note where I was just going to define .NET?

I couldn't find anyone else taking a deep IT perspective on .NET; I hope this series has been helpful to you.

I think .NET is important, and I've tried to share my reasoning with you. I don't mean it's important for Microsoft, though it is that; rather, it's important for IT departments that want to become more agile, more productive, more of a value-add for their business rather than just a cost center. I've gone into such detail because I want IT to matter.

If we in IT are more agile, our companies will be more agile, and more successful. The dotcom boom is over; in the business world, profit again matters. I think .NET can make a real difference on that path to business profitability.

I really do enjoy reading your comments and thoughts, though I can't respond to all of them; feel free to write me about this series, or about whatever's on your mind about TechNet or IT.

Steven B. Levy

Microsoft TechNet