Home
 > Research and Reports > TEC Blog > Microsoft .NET-managed Code Enablement: Examples and Chal...

Microsoft .NET-managed Code Enablement: Examples and Challenges

Written By: Predrag Jakovljevic
Published On: October 5 2006

Microsoft .NET Examples

Developing and deploying a Web service-connected information technology (IT) architecture is no small task. To that end, the Microsoft .NET Framework provides what a business might need: smart clients, servers to host Web services, the development tools and applications to create and use them, and a global network of over 35,000 Microsoft Certified Partner organizations to provide help for users.

Part Four of the series Subtle (or Not-so-subtle) Nuances of Microsoft .NET Enablement.

For a general discussion of the evolution of system architecture, see Architecture Evolution: From Mainframes to Service-oriented Architecture. For a definition of how the Microsoft .NET environment addresses the situation, see Subtle (or Not-so-subtle) Nuances of Microsoft .NET Enablement.

Example One: Intuitive Manufacturing Systems

The first example of a .NET-managed product is Intuitive Manufacturing Systems, a Kirkland, Washington (US)-based provider of extended enterprise resource planning (ERP) solutions for small and midsize discrete manufacturers (Intuitive Manufacturing Systems Shows Maturity in Adolescent Age). The company was recently acquired by ravenous (lately, anyway) fellow mid-market vendor Made2Manage Systems (see Made2Manage Systems One Year After: Reenergized and Growing). Intuitive's .NET technological prowess was cited as one of major attraction points, given that most of Made2Manage's ERP product lines were (at best) somewhere between the .NET-compatible and .NET-enabled evolutionary steps at the time.

Intuitive recently announced the milestone release of Intuitive ERP 8.0, which represents the completion of a major rewrite of Intuitive ERP functionality using .NET-managed code, which started a few years ago. With this release, all major manufacturing processes have been converted to the new architecture. Additionally, several areas of new functionality are now offered in Intuitive ERP 8.0, including new engineering change order (ECO) processes to support new product introduction (NPI) as well as engineering change requests (ECR) to facilitate getting improved product to market faster.

There are also approved supplier tools designed specifically for the growing contract manufacturing industry, which replace the commonly used but inefficient and mistake-prone spreadsheets. Last but not least, to support the demand-driven supply chain, material and capacity requirements planning runs now typically take minutes, eliminating those traditional long planning runs, and thus allowing on-demand planning. Version 8.0 was available to new customers in May 2006, and existing customers will be able to upgrade to Version 8.1, (scheduled for late 2006), when the migration tools should be available.

One should note that Web services are created naturally as a by-product of .NET-managed software, although they are also created naturally as a by-product of the Progress OpenEdge .NET support in, for example, Epicor Vantage (which has not been completely rewritten in pure .NET-managed code). To that end, Intuitive has componentized the business logic into granular .NET objects, whereby all transactions occur in extensible markup language (XML). This means, for one thing, that at Intuitive a Web service is different than elsewhere: many other mid-market vendors have chosen to add "wrappers" to whole legacy applications (such as customer resource management [CRM] or purchasing) , and advertise the ability of these applications to run on an ERP backbone as a composite application or service-oriented architecture (SOA). Some market research surveys show that although this may play well to complex and diverse tier one environments, the concept will not necessarily be embraced by mid-market manufacturers with more homogenous software platforms. Instead, Intuitive has worked hard to split up its applications into usable pieces of functionality that make business sense.

In fact, Web services is simply a "neat" technology until it is actually used. Applying this concept to the demand-driven supply chain, a real-world example of a granular business application is the available-to-promise (ATP) or capable-to-promise (CTP) Web service available in Intuitive ERP 8.0. To make it even more valuable, an Intuitive ERP user will be able to provide key customers with access to the ATP and CTP Web services through Microsoft Office Outlook (with the upcoming release of Microsoft Office 2007) for what-if planning scenarios, thus providing practical supply chain collaboration in real time. Supply chain partners will be able to make decisions quickly based on delivery dates and quantities from current production or stock (using ATP) and from new production plans (using CTP) without having to wait for a return call or e-mail.

Furthermore, the source of a transaction remains transparent in the innovative Intuitive Framework. In other words, whether the transaction comes from Intuitive ERP users who are interactively entering it on their computer, or from the outside world (as a Web service), the framework uses a single set of business logic. This should eliminate the gamut of problems that traditionally exist in other applications, where duplicate sets of code are required for different sources of transaction requests and data. Web services technology is still fairly young, and not as robust as it needs to be to fulfill its promise, and .NET-managed makes it easier to write, deploy, and consume Web services. Unfortunately, many of the other huge benefits of the .NET-managed environment (such as coherence of an integrated environment) are getting drowned out in all the ongoing hype surrounding Web services and SOA.

Example Two: VISIBILITY.net

Another provider of an ERP solution that uses .NET Framework-based SOA and .NET-managed code is Andover, Massachusetts (US)-based Visibility Corporation. Since 1980, its suite VISIBILITY has been used by about 150 manufacturers of engineered products, and by other companies with project-oriented concerns. Now in its seventh generation, with the product dubbed VISIBILITY.net, the company elected to forego the use of wrappers to deliver .NET Framework-based functionality. To that end, the vendor has invested the last four years performing a complete conversion of the core client/server-based application to make use of a pure .NET-managed code architecture enabled via the use of Web services and Active Server Page (ASP).NET forms. The approach used here has provided clients with a true zero-footprint client for deployment, where no component other than a browser is required on the client workstation.

The benefits of the approach used in the VISIBILITY.net application are multiple, including a significant reduction in the amount of code required to deliver the more than 1,000 new distinct functions; a reported threefold to fourfold increase in transaction performance and associated scalability; and a reduction in the cost of deployment and management, as the application can be run by any client capable of running Microsoft Internet Explorer (IE) v5.5 SP2 or later as its browser. By abstracting the application model to make use of managed code and Web services, which distinctly deploy the form, business logic, and data connection layers, Visibility has reportedly gained ability in affecting database independence, improved run time performance, and application extensibility in relation to other applications which make use of a well-formed SOA.

Example Three: Epicor for Service Enterprises

The last example of a Microsoft-only stack product containing pure .NET-managed code and "militantly" componentized Web services, is Epicor for Service Enterprises, a brand new enterprise service automation (ESA) solution. This product aims at providing a single source for managing and automating most aspects of the project-focused organization. The product is written completely in .NET-managed code, and on the very latest Microsoft .NET Framework 2.0, Microsoft SQL Server 2005, VS.NET 2005, and Web services. To be precise, the latest version (8.1.1), which became generally available just a few weeks ago, runs on SQL Server 2005, .NET Framework 1.1 and VS.NET 2003. Certification for the move to .NET 2.0 and VS.NET 2005 is in progress, and is expected to become available in the next few months along with Microsoft Project 2007 support as part of Epicor's commitment to support the latest Microsoft stack at all times. In any case, this application did take several years to write from scratch (the initial release was in June 2003, and currently has more than 70 customers and 25,000 seats) and, contrary to its brethren within Epicor, is limited to only Microsoft technology because of the approach—but it also has the benefits of .NET as mentioned above.

Furthermore, the product is backed up by the Epicor Internet Component Environment (ICE), which is a standards-based framework written with Microsoft VS.NET and running on top of the Microsoft .NET Framework. It offers an application development environment (customization and extensibility tools for assembly, deployment, execution, and maintenance of applications) with a feature-rich (albeit thin client) user interface (UI), and pure web access to clients. Using Web services for nearly all application logic, Epicor ICE provides a detachable and vastly configurable UI that is simple to deploy and easy to maintain.

As for some of the many other components of Epicor ICE that vouch for agility, one might point out that the combination of Epicor ICE and business process management (BPM) technology enables companies to automate and streamline business processes for continuous improvement. To that end, ICE BPM Director serves as a workflow and business process solution within the ICE platform, including framework support for business event messaging, and a business orchestration application. Both application developers and information workers can use BPM Director to coordinate business processes, orchestrate workflows, and automate decision-making (see Business Process Management: A Crash Course on What It Entails and Why to Use It).

No Approach Is Without Challenges

Intuitive ERP, Epicor, VISIBILITY.net, and Microsoft Dynamics CRM are examples of the few products that are all but completely .NET-managed. There are also indications that future versions of the Microsoft Dynamics ERP product lines will increasingly be written in the managed .NET code. All this might indicate the ultimate aim, but the principal challenge of this approach is that it requires a time-consuming rewrite of functionality. The transformation, which entails converting or rewriting every single line of software code and modifying the products' architectural design to leverage the many touted benefits of the .NET Framework, will not likely be painless for the install base. Converting a software product to be fully .NET Framework-based is a big effort. No software vendor should simply convert lines of code from their old language to a new .NET Framework-based language, and recompile those lines using a .NET compiler. A wise conversion should include substantial product redesign to take advantage of the many new features of the .NET environment, satisfy new Internet connectivity requirements, and better position the product to adapt to the even more advanced technology that will appear in the long term.

In fact, as long as the "old" software is meeting business needs, new technology is not the change driver, which makes building replacement products on a new framework a higher risk strategy. Some of the ".NET-enabled only" products are now in their umpteenth generation, which has given the vendors the chance to optimize their code and solve many security and other conflicting issues. Product functionality still matters quite a lot, and while it is important for enterprise applications providers to implement the latest computer science "quantum leap," there is no guaranteed correlation between first-to-market and ultimate success in the market. In fact, based on many experiences, including Intuitive's recent acquisition, one could even argue that there might be an inverse correlation. Many vendors have also felt the displeasure of client bases that were far from ready to make a significant technological leap. Hence, having been burdened with a large customer base still running on a slew of older products supporting possibly obsolete technologies, even the largest vendors have had to backpedal and rethink their older product release discontinuation strategies.

Although.NET-managed software indeed features the touted snazzy Windows XP features (whereas the quickly ageing COM-based chunks of functionality still exhibit the "boxy" Windows 98 feel), one can think of only a few compelling functional enhancements that would justify existing opting for the product at this stage. Certainly, .NET technology makes it easier for developers to produce rich, vividly colorful UIs, since .NET makes it easy to use the new richer-detailed 48x48-pixel icons, color gradients that fade from one color to another, and rich and finely detailed graphs and charts.

Also, .NET Framework-based software is inherently speedier, especially when accessing Microsoft SQL Server databases, but it is not very likely that these will be compelling reasons for ordinary, non IT-oriented users to embark on painstaking migration path. In other words, at this stage the "if it ain't broke, don't fix it" mindset may likely work against Intuitive, Visibility, and Microsoft, unless these vendors can prove a better value proposition, such as more rapid development of new vertical functionality. Not many users are savvy enough to realize that the systems that have added Microsoft code around an old technology core have to deal with translation between the old and new layers; data typing; formatting, interface, and performance issues; version compatibility dilemmas; and other subtle problems.

Conclusion and Recommendations

By way of concluding words of advice, business rationale should always drive any technical decisions. Every business should focus on optimizing processes and core competencies, such as lowering costs, improving customer satisfaction, achieving faster deliveries, and so forth. Then, painstaking exercises should be conducted to determine the technological enablers. For the vast majority of enterprises, future IT asset portfolios will still feature a mix of packaged and homegrown legacy applications, and not total rewrites. In other words, many vendors might be happy with (for example) only leveraging web applications with ASP.NET or the new UI within the .NET Framework 3.0, but not with conducting a total core system rewrite. A good example of how involved the decision can be is the Made2Manage and Intuitive merger. Namely, Intuitive's .NET-managed technology will become the foundation going forward, but the decisions about whether to rewrite existing Made2Manage ERP modules in .NET-managed code or simply to.NET-enable them via Web service wrappers is still being pondered and weighed from all angles. Certainly, any new functionality will be written in .NET-managed code.

Microsoft-centric users should deeply consider whether the ultimate panacea is .NET-managed code software. It does avoid many of the problems that users experience in traditional Microsoft Windows software, such as the (in)famous "DLL hell," complex installation processes, poor un-installation, and so forth. It sidesteps the root causes of many of the bugs and security problems users suffer from. Such.NET-managed code systems will be easier to install and administer, and therefore cheaper to own over the long haul, and such systems will be easier to secure against hackers. Also, .NET-based systems will be less buggy and better behaved, and "blue screen" mystery crashes should be a thing of the past. Fewer problems means less wasted time for users and IT professionals, but is that compelling enough at this stage? There is no universal answer for the prospective user. For some, it might suffice to know that the product has been architected using business objects and components, and the XML standard. This is at least the first indication of whether the product is truly enabled for .NET, or for "NOT.YET."

This concludes the series Subtle (or Not-so-subtle) Nuances of Microsoft .NET Enablement.

 
comments powered by Disqus

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.