Enterprise Resource Planning (ERP) systems are like wine: they get better with age. Microsoft Dynamics NAV 2009—a member of a broader Microsoft Dynamics family of products—is an ERP system targeted at small and medium-sized businesses, which didn't just get better with its latest release, it brought a revolution. It has got a new face, and new brains, and it is off to change the ways of all participants of the ERP food chain: the consultants, the developers, and the end users alike.
In this chapter you will learn:
Why Microsoft Dynamics NAV 2009 is so special
Whether the RoleTailored client is worth all the buzz
Why the new architecture is so important
What it takes to implement Microsoft Dynamics NAV
How the future of Microsoft Dynamics NAV will look
Microsoft Dynamics NAV 2009 is the most significant release of the product ever made. What's new in Microsoft Dynamics NAV 2009? Nothing. And everything.
If you're looking for additional enterprise resource planning application functionality (something that an ERP system should be all about), indeed there is nothing new. Just compare Microsoft Dynamics NAV 2009 to the previous version (Microsoft Dynamics NAV 5.0 SP1), and you'll find the same old application areas, the same old functionality. Not even one new business process is covered. If you're shopping for these things, you're going home empty handed.
So, nothing is new.
But there's more to life than application functionality. Previous releases have included plenty of new features, new modules, and some cosmetic changes to the user interface. This release is about something else, so let me announce in my best Monty Python voice: And Now for Something Completely Different!
If you're an old-hand with Microsoft Dynamics NAV, when you start the new client, you'll see an application unlike any version you've seen before. It doesn't look like the Microsoft Dynamics NAV you've been used to, and has very little in common with previous user interfaces. Meet the RoleTailored user interface.
If you are new to Microsoft Dynamics NAV, you're going to fall in love with this little puppy in no time at all. It's simple and intuitive, so intuitive in fact that you'll start clicking around it productively the moment you see it. It redefines user friendliness.
However, if you are a Microsoft Dynamics NAV veteran (one of those that still remembers what NAV is short for), if you can keyboard your way around the application, reconcile a bank account or cancel a purchase return order blindfolded, the RoleTailored user interface is going to challenge you and it may be a while before you grow fond of it. But make sure you do grow fond of it, and do it fast: the RoleTailored interface is here to stay, it's about to define the future of all Microsoft Dynamics ERP products, and will change the way users interact with Microsoft Dynamics NAV for ever.
The RoleTailored user interface gets its name for a reason: at its core are user roles that define sets of specific actions and tasks that different types of users perform in the course of their daily job. Users belonging to different roles will have a different view of the system, each of them seeing only those functions they need to be able to perform their daily tasks.
The RoleTailored user interface hides the complexity of the system away from the users, and replaces it with clarity; so users can spend more time productively working with the application instead of searching for functions among dozens of unneeded ones.
If you had a chance to work with Microsoft Dynamics NAV 4.0 or 5.0, you might remember how difficult it sometimes was to locate a specific feature in the jungle of the Navigation Pane. Switching back and forth the specific menus in search of a menu item, especially for users performing tasks in several functional areas of the application, was a frustrating experience.
Unless you used shortcuts, accessing any feature required three of four clicks—provided you knew exactly where it was. The system also didn't do much to help users focus on what needed to be done, and after you found the feature you needed, you typically had to spend extra time searching for documents or tasks that needed your attention. For example, if you needed to post a released invoice, you first had to click your way through to the Invoices feature, and then you had to search for those that were ready to be posted. This required too many clicks and far more interaction than really necessary. All in all, productivity was hindered by technology.
With the RoleTailored client, the feature jungle is gone, and the application isn't even showing you the features you don't need. Your role is defining what tasks you need to perform, so your screen isn't cluttered with functions you'll never use. Work that needs your immediate attention—such as invoices waiting to be posted, or production orders to be released—is always one click away and readily presented using visual cues. Thus, your focus is never taken away and you don't waste time on unnecessary human-machine interaction.
Consultants implementing Microsoft Dynamics NAV 2009 for their customers will need to master a completely new understanding of the customer's business model: an understanding that is focused on user roles. This understanding is necessary to successfully map the end users to existing roles, or to define new ones—a prerequisite for achieving any benefit from the RoleTailored experience and improving the user productivity. We'll help you to get that understanding in our chapter on Roles and the Customer Model.
Microsoft Dynamics NAV 2009 has a nice-looking user interface but true changes are beneath the surface in the new architecture, and many benefits it has brought along. Building a distributed system, deploying a hosted environment, or achieving higher scalability are among the most obvious ones.
The true beauty of the new architecture is that it breaks down the barriers that kept Microsoft Dynamics NAV a relatively closed system, one that was difficult to extend beyond the boundaries of its own user interface. Integrating ERP functionality into workflows having their start or endpoint in external systems (such as master data management procedures or e-commerce scenarios) was difficult, expensive, or both in earlier versions.
Old, two-tiered architecture didn't scale too well; you were normally limited to a couple of hundred concurrent users, and that was only if you had a top-notch multiprocessor database server with gigabytes of RAM. You couldn't extend it easily outside of the realm of the C/SIDE development environment and C/AL language, unless you got medieval on yourself venturing into realm of C/FRONT and its arcane techniques. The new architecture changes all this.
With the new architecture, these boundaries are gone, and you can go as far as your creativity allows. Exposing almost any application functionality as a Web service ready to be consumed by external applications is a matter of simple configuration settings, and connecting just about anything that can speak SOAP (Simple Object Access Protocol, the Web services communication standard) to Microsoft Dynamics NAV can be accomplished on the fly. Meet the Web services-enabled three-tier architecture.
Three-tiered architectures generally provide better scalability; in fact, they are a prerequisite for it. The Microsoft Dynamics NAV 2009 three-tier architecture improves the overall scalability of Microsoft Dynamics NAV, and its central component—the Microsoft Dynamics NAV Server—is what makes it possible. You can also deploy several Microsoft Dynamics NAV Servers in parallel, and connect them to the same database, thus achieving higher scalability levels, especially when you want to separate the workload of several departments to dedicated machines.
Microsoft Dynamics NAV Server takes over a substantial share of the chores from the client, namely the execution of business logic. This reduces network traffic because only a small amount of data travels between the server and the client. It also shortens locking times because no or very little data exchange needs to happen between the server and the client during long transactions.
The new Web services-enabled architecture means that now you can use Visual Studio to write applications that build upon Microsoft Dynamics NAV functionality, and to seamlessly integrate it into workflows that start or end completely outside Microsoft Dynamics NAV.
All of this was next to impossible in the previous versions. Microsoft Dynamics NAV of old is no more—it has grown from a simple application into a fully-fledged platform. It gives much more out of the box, and makes it possible for you to take your implementations far beyond anything possible with the previous version.
So, everything is new.
A business is like a living organism; it contains dozens of functions, which all work towards a common goal: success. Business departments, while all being a part of a much bigger system, have their own needs, targets, and processes, and sometimes can thrive totally oblivious of the existence or function of other departments.
Marketing can launch campaigns totally unaffected by the headaches manufacturing might be going through, warehousing can ship and receive pallets regardless of what accounting might have on their mind, and all of them can be successful in their own right. But the success of a business is not just the sum of successes of individual departments—for a business to succeed, all departments must work in harmony.
Enterprise Resource Planning, or ERP, is a paradigm that integrates data and processes from all departments into a single software platform, which not only serves the needs of each individual department, but also the needs of the business as a whole.
Every business is unique: they all do accounting, purchases and sales, but each of them does it in its own unique way. The software they use to run business should play along, and allow them to operate successfully, while giving them freedom to do it their way.
Microsoft Dynamics NAV 2009 is a feature-rich and highly customizable ERP solution: it comes bundled with a lot of standard functionality, which can be used as is, or customized to exactly match specific processes of a company. To put it to work successfully, it takes much more than merely installing it. The process which transforms it from a generic solution to a highly specialized one able to cope with mission-critical requirements and carry the bulk of the day-to-day business operations is called implementation.
Implementation is a journey, which starts with understanding the application. You need to know the user interface, how to operate it, how to customize it to fit the requirements of a business, and how to personalize it to best match the users' preferences and unique needs. The RoleTailored interface of Microsoft Dynamics NAV 2009 offers a wealth of personalization capabilities: users can add or remove screen elements and functions and make the interface feel comfortable to them. This allows users to focus on their tasks and activities instead of wasting time on unnecessary interaction with the system.
Microsoft has developed a customer model with a set of pre-defined user roles, based on the roles typically found in today's businesses. During implementation, you'll meet your end users and learn their daily routine. This knowledge will help you map your customer's model to the Microsoft Dynamics NAV's default one, and develop the role centers custom-tailored to specific needs of your users to boost their productivity and increase satisfaction.
To successfully implement Microsoft Dynamics NAV 2009, you need to know its standard functionality, and the kinds of business processes it can support. During the implementation, you'll analyze the business processes of your customer and understand how they relate to Microsoft Dynamics NAV 2009 application areas.
Microsoft Dynamics NAV 2009 is not a my-way-or-the-highway kind of application: its rich configuration capabilities make it possible to establish many business rules using application setup alone. Application setup is a central part of every implementation, and you'll spend a lot of time discussing various settings with your customer: general ledger, posting rules, dimensions (just to name a few).
When it is not possible to achieve what you need using setup, you'll reach for built-in customization and development tools that allow you to modify existing functionality or to develop a new one. Depending on the complexity of your customer's requirements, you might be able to modify the application without any programming knowledge, and even if you are not a programmer you can go a long way in developing a data model, user interface, or reports.
Microsoft Dynamics NAV 2009 is more than just an ERP system or a business management solution—it is a true platform that can be used to build upon. Developing inside it, using built-in development tools is not what makes it a platform; it's the architecture that does it. The Web services enablement allows publishing application functionality as a Web services, and makes it possible to develop distributed applications over Microsoft Dynamics NAV, or include and seamlessly integrate its functionality in third-party or custom-developed applications without hassle.
While implementing Microsoft Dynamics NAV you should bear in mind that you are not merely introducing an application into a business environment; you are dealing with business-critical processes. The solution you are implementing will be used on daily basis, probably throughout the company; it will run or control high-stake processes, such as invoicing, tax reporting, and inventory management, and it will have potential to enhance the way your customer does their business, or to bring it to a complete halt. That's why it is important to understand what the implementation process looks like, and how to smoothly drive it from initiation to a successful closure.
Like any other ERP application, Microsoft Dynamics NAV 2009 comes with many application areas that can be used independently of each other. In ERP terminology these are called modules, and they allow great flexibility in dealing with an enormous variety of business requirements. Customers in different business branches, or verticals, will use different modules: a manufacturing company might use all of the ERP modules, while a government agency or a public-sector company might only need financials, purchases, and human resources functionality. Even though these modules are separate in ERP systems, they are all integrated into a single application, and all use the same integrated database.
Strictly speaking, Microsoft Dynamics NAV does not have modules in the typical ERP meaning of the word: the functionality is so tightly integrated that there is no clear boundary between functional areas. And this is exactly what we call them in Microsoft Dynamics NAV.
Financial Management: As a cornerstone of every business management system, this functional area includes functionality necessary for managing finances of a company. Financial management consists of general ledger, cash management, accounts payable, accounts receivable, fixed assets, and inventory costing. Comprehensive financial analytics and history of financial transactions is also included.
Sales & Marketing: Usually this functional area comes as a series of modules in other ERP systems, but they all have one thing in common—they all cover the customer-facing activities of a company. Microsoft Dynamics NAV packs all this functionality into a single functional area, which includes sales order processing, marketing, pricing, and Customer Relationship Management.
Purchase Management: As an important component of what other ERP systems usually bundle as Supply Chain Management, this functional area provides functionality for handling the input of goods into the company. It includes planning and purchase order processing.
Warehouse Management: This too belongs to Supply Chain Management; this functional area takes care of warehouse processes and handling of goods once they enter the company. In Microsoft Dynamics NAV, this functional area consists of order management, planning, goods handling, and inventory management.
Manufacturing: Usually this functional area is at the very core of every Supply Chain Management system; the manufacturing module delivers all the functionality necessary for tracking and managing conversion of raw materials into finished products. In Microsoft Dynamics NAV, this functional area comprises product design, capacity planning, production planning, production order management, and manufacturing costing.
Jobs: This functional area is what other ERP systems usually call project management; it is used to track projects undertaken by the company, and it consists of job planning and costing. This should not be confused with project management tools, because it is primarily used to track projects from a financial perspective.
Resource Planning: If you sell services, this functional area contains the necessary functionality for planning and managing the resource availability and usage. It includes resource planning, pricing, and resource capacity management.
Service Management: Typically, the Service Management module is part of Customer Relationship Management, but in Microsoft Dynamics NAV it is a separate functional area comprising contract management, service planning and dispatching, and service order processing.
Human Resources: This manages the workforce through the functionality of employee record management and time and attendance. While most other ERP systems include comprehensive functionality including payroll and benefits, Microsoft Dynamics NAV stays at the most basic functionality allowing partners to build upon it.
Many features of one application area can also be found in another, such as inventory management or costing functionality, which is interspersed through the Financial Management, Sales & Marketing, Purchase, Warehouse, and Manufacturing functional areas. This improves user experience for users of the Classic client, because it is one of the mechanisms that reduce the time spent on searching for functions.
Most of the functional areas in Microsoft Dynamics NAV 2009 also include analytics functionality, which allows detailed analysis of information stored in the system. Another important common functionality is transaction history, which allows fast and easy finding of literally any transaction and the effects it had on the system.
Contemporary ERP systems rarely exist in isolation. The imperatives of agile business demand that anything that can be automated gets automated, and anything that can be integrated gets integrated. Microsoft Dynamics NAV 2009 readily integrates with lots of other products, raising productivity to a completely new level.
Microsoft Dynamics NAV can utilize Microsoft BizTalk Server for business-to-business communication and automation of Supply Chain Management, through the built-in Commerce Gateway functionality. In much the same way, Microsoft Office SharePoint Server (MOSS) can be used to enable access to the system through a web browser interface. Microsoft Dynamics NAV 2009 also bundles a feature-rich integration with Microsoft Outlook. All of this functionality saves a lot of time and spares the system from human error, which otherwise can't be completely avoided.
The architecture of any system is among its most important components. It affects many aspects of it: how the system will perform, how it will be able to scale, how secure it will be, how difficult it will be to integrate it with other systems. These depend a great deal, if not exclusively, on architecture.
With Microsoft Dynamics NAV, architecture was a constant for a long time and it withstood dozens of releases almost completely intact. There was certain lore to it among developers and consultants—functionality could change, features got included or dropped, but you could depend on the architecture, it remained the same release after release. Then the advent of Microsoft Dynamics NAV 2009 turned the architecture upside down.
Business applications usually have three discernible layers: presentation, business logic, and data. How exactly these layers are structured is defined through architecture. While the term may seem somewhat outdated these days, Microsoft Dynamics NAV has long been built around a Client/Server architecture.
A Client/Server architecture presumes that there are two layers, or tiers, in the system—a client and a server. The client is used for presenting the user interface to the user, while server is used to store the data. The most important part, however, is the business logic, and either of the tiers can do the processing, effectively resulting in two possible two-tier architectures.
The first one, popularly called the thin client architecture, uses the client as a mere data presentation and entry device, while all business logic is processed centrally at the server. The server sends the data to the client, which presents the data to the user. When the user changes data, the client submits it back to the server, and any necessary processing is done away from the client. With thin client architectures, clients are very simple and cheap, while the servers are big, powerful, and usually very expensive.
The second one, called the fat client, goes the other way around, putting the burden of processing the business logic on the client. The server is used just to handle the data storage and management operations, while the client does everything else. This approach leverages the fact that most of the client computers are powerful, and that all this power remains largely underutilized. With so many resources readily at the disposal of a system, the fat client approach results in relieving the server from the work that can be done at the client, saving the costs of building an expensive server system.
Although neither of these approaches is inherently good or bad, and both come with their share of pros and cons, two-tier architectures in general leave a lot to be desired. Just to start with, they can't scale. Two of the three mentioned components are particularly resource-hungry: business logic and data processing.
If you put the burden of business logic on the server, then the server has to do both logic and data processing. These two tasks can easily and quickly eat up all system resources if done simultaneously for bigger number of concurrent connections. Even though the server is perfectly capable of accepting more connections, or in other words scaling up, its nailed-down system resources are preventing it from doing so.
On the other hand, if the burden of business logic is on the client, and the client only needs to process a single connection at a time, the client resources are utilized in a rather effective way, but the concurrency is affected terribly. Hardly any transaction consists of just a single write operation, and there are many reads and writes going on all the time. This results in many locks being placed all over the database, and with a network being a far slower a resource than a server bus, while one client processes a transaction through the network, most other clients need to queue up and wait for their turn. Even the fastest of network environments will hit their limits with a fairly low number of users working concurrently in the system.
Three-tier architectures introduce a middle tier, which takes over the business logic processing, thus completely isolating all the components of the system to separate tiers. This brings significant improvements over two-tier approaches, by combining the benefits of both fat-client and thin-client approaches, while effectively overcoming their limitations.
The middle tier takes business logic processing away from the database tier, leaving the database to handle a single task of data processing. At the same time, with business logic being processed at the server, clients only need to feed the data to the middle tier once per transaction. Instead of having dozens of clients attacking the database server randomly and locking its resources at will, the middle tier can efficiently marshal the requests, resulting in more synchronized communication, which doesn't adversely affect concurrency as much as random access does. This results in considerably increased scalability.
Microsoft Dynamics NAV has long been a fat client two-tier Client/Server architecture system. It consisted of a client, which processed both the user interface and business logic, and a server, which only processed the data. Obviously, with this approach, achieving high scalability levels was difficult.
Microsoft Dynamics NAV 2009 comes with both two-tier and three-tier architectures. For backward compatibility, the two-tier architecture is retained through the Classic client, which is basically the same C/SIDE client that most of us have been used to working with in previous versions. For new features, such as the RoleTailored client or Web services enablement, there is the new three-tier architecture:
Let's get to know the important components of Microsoft Dynamics NAV's three-tier architecture: the RoleTailored client and the Service Tier. Note that the database tier is the same one used in two-tier architecture, and is used only to store the data, so we are not going to investigate it in detail.
Microsoft Dynamics NAV 2009 has introduced a new Client Tier component that is completely different from the fat Classic client. The main design goal of the new Client Tier was not to develop the shiny new RoleTailored client application, but to allow for a future inclusion of any number of different client applications which could run on different hardware or software platforms and still provide the same functionality and the same RoleTailored user experience.
Data Binder: Data is just stored in the database, but it doesn't live there. It is continually transferred between the client and the server, courtesy of the Data Binder component. It is also in charge of all notifications sent back and forth between the user interface and business logic layers.
Form Builder: The trickiest of components, the Form Builder builds logical display-independent forms, based on Pages metadata stored in the database. These forms contain all functionality regardless of the display target, including data binding, input validation, and any business logic. Any display target builds its own specific version of the form, based on this logical form.
RoleTailored Client: The logical runtime which is bound to a concrete display target technology. The architecture of previous two components allows for more than only one possible display target. Currently, only WinForms display target is released, which is called the RoleTailored client, but more could be built in the future. This open design will allow Microsoft Dynamics NAV to expose a single set of pages across a wide variety of display target technologies, with very few or no modifications of the page definitions.
The RoleTailored user interface is one of the most important additions to Microsoft Dynamics NAV 2009, and you will get a chance to learn about the role-based experience and RoleTailored user interface of Microsoft Dynamics NAV 2009 in great detail in the next chapter.
T he middle tier of any three-tier architecture is usually the one that is responsible for most of the legwork the system has to do. Microsoft Dynamics NAV 2009 is no different, and the Service Tier, which comprises several components, carries the bulk of the processing of the whole system.
The Microsoft Dynamics NAV Service Tier is not a single component, and the work is distributed among the following components:
The Microsoft Dynamics NAV Service: A workhorse of Microsoft Dynamics NAV 2009 Service Tier, this is the connection point between the client and the system. It works in the context of a Windows service built on Windows Communication Foundation (WCF) and .NET. It also handles authentication and thread management, and functions as a broker which receives and validates requests from the client, and then routes them to the proper service component for execution. After the execution completes, the response is returned back to the client.
The Application Component: Although this component is really a new gadget in the Microsoft Dynamics NAV arsenal, it is just a shiny wrapping around the well-known application logic. The application logic is still written in C/AL, but is compiled into a .NET assembly at design time. At run time it executes on top of Microsoft Dynamics NAV Class Library.
Microsoft Dynamics NAV Class Library (NCL): As the most interesting part of the Service Tier, this is actually the Microsoft Dynamics NAV runtime wrapped as a .NET class library. It is a non-public library, which means that developers will not be able to inherit from it or extend it directly, in much the same way as the Classic client itself has always been out of the reach of developers. This component is hence used only to port the functionality of the Microsoft Dynamics NAV environment into the world of managed code and .NET interoperability, which makes it possible to run it in the context of Web services.
The Metadata Provider: This handles all sorts of metadata that circulates between the client and the server, and there is a decent share of it. It is primarily used to feed the form metadata, the personalization metadata, and table metadata to the Form Builder and Data Binder components of the RoleTailored user interface. It also handles the filtering of the metadata based on licensing and permission restrictions, and language settings.
Business Web services: This component provides interfaces necessary for connecting external or third-party applications to Microsoft Dynamics NAV 2009. It supports operations such as reading, creating, modifying, and deleting of data in Microsoft Dynamics NAV, while invoking any necessary business logic and executing any code pertinent to such operations. Examples of these would be execution of any field validation triggers, or initialization of proper number series when inserting new master data records. It resides in the same .NET assembly as Microsoft Dynamics NAV Service.
Web services confusion: When talking about Web services in context of Microsoft technology, it is natural that people immediately assume that Internet Information Services (IIS) is involved. However, this assumption is wrong.
Microsoft Dynamics NAV Service Tier doesn't use IIS. Instead, it is built on Windows Communication Foundation (WCF), a set of .NET technologies (formerly code-named Indigo). Compared to IIS, WCF has much less overhead, both in the number of execution layers and in setup and administration, thus resulting in faster and more streamlined communication.
Microsoft Dynamics NAV Service and Business Web services components are both built upon WCF and reside in the same .NET assembly, which publishes two separate Windows services: one used for native communication between the RoleTailored client and the Service Tier, and one for Web services enablement.
Obviously, Microsoft Dynamics NAV 2009 goes much further than just providing a new fancy user interface—it finally introduces the product into the ubiquitous world of Service Oriented Architecture. While extending the application with genuine non-C/SIDE functionality in previous versions of Microsoft Dynamics NAV was almost literally restricted to programming the arcane C/FRONT interface, which never truly saw much action, the new architecture provides the entire infrastructure needed to have external applications access and integrate with the Microsoft Dynamics NAV functionality.
The biggest excitement with these components is that they are not here only to carry the weight of the RoleTailored user interface, but they pave the road for many other user interfaces to take advantage of Microsoft Dynamics NAV infrastructure. The RoleTailored client is just the first one that does so, and many more, such as the SharePoint interface, which is planned to follow the release of Microsoft Dynamics NAV 2009 shortly, can be expected to follow.
The simplest of examples of what you can effortlessly achieve with Microsoft Dynamics NAV 2009, but which called for a tremendous amount of work previously, is a web interface that will fully and consistently execute the Microsoft Dynamics NAV business logic. Writing a web application, such as a web shop or a self-service portal for customers or vendors, which consumes Web services published through Microsoft Dynamics NAV and seamlessly integrates with its business logic, is as simple as writing any Web services-aware application, and doesn't require any black-belt programming knowledge or skills.
Therefore, the new architecture provides as much opportunity to third-party solution providers as it does to customers.
Ever since Microsoft took the helm of the Danish company called Navision A/S in 2002, one of the great benefits for Microsoft Dynamics NAV customers has been the clear and up-to-date roadmap of the product. Customers have never been kept in the dark regarding what future versions will bring, or where the product would be in years ahead, reassuring them of the security of their investment into Microsoft Dynamics NAV technology.
Microsoft's ongoing strategy for Microsoft Dynamics NAV is to continually deliver a competitive product, which brings more value to mid-size businesses than its rivals. This is going to be done by improving application functionality and enhancing user experience.
With Microsoft Dynamics NAV 2009 paving the way for role-based and role-centric customer models, future versions might build upon this foundation, and deliver broader user roles functionality. Also, new application features have consistently been introduced over past versions, so any future releases can be expected to come packed with new features and application functionality. Another trend has been evident since version 5.0, which is inclusion of broader global functionality, and with Microsoft's official introduction of modules such as Kitting or Cost Accounting, it can reasonably be expected that more such functionality will be introduced in future versions.
From development perspective, Microsoft Dynamics NAV 2009 has made a big step forward. With Visual Studio debugging of C# code it is now possible to integrate non-C/AL developers into development and testing teams. While not that exciting for .NET veterans, introduction of features such as color-coding in the C/AL editor really reassure the partners that the improved development experience is in focus for future versions of Microsoft Dynamics NAV.
Microsoft Dynamics NAV SQL Server option has been getting better in performance with every new release, while Microsoft Dynamics Classic database server has reached its limit a long time ago. This, along with the fact that three-tier architecture doesn't even support the Classic database server, makes it obvious that Classic database will gradually be phased out.
A major driver for the development of future versions of Microsoft Dynamics NAV, as well as of all products within the Microsoft Dynamics line, is customer-driven innovation—a simple concept of delivering what customers really need. Microsoft has invested significant effort into engaging in dialogue with customers and partners about the future of Microsoft Dynamics products and their roadmaps.
As a result of this research, three major areas of Microsoft Dynamics NAV 2009 can be expected to go through many improvements over the several next product versions:
Business Vision + Software: An area that has always gone through the most improvements in every new version, with application feature list getting ever more comprehensive. This trend can be expected to continue, probably with some shift towards more vertical and industry-ready solutions. Future versions may bring even more productivity enhancements, such as those already achieved with the RoleTailored client, together with better integration with Microsoft Office and the Server System stack of products. Improvements in SQL Server integration have always been among the top priorities. Teaching old dogs new tricks has never been a simple job, and converting a two-tier solution—initially not architected to leverage the benefits of a true relational database management system such as SQL Server—to a fully scalable multi-tier system and not causing any regression issues in the process, is a fantastic feat. Now that Microsoft Dynamics NAV has finally got its middle tier, and that SQL Server 2008 is out, true improvements are yet to be seen.
People + Processes: Microsoft's focus on overall user experience is evident—and not only in Microsoft Dynamics line of products—therefore significant enhancements can be expected here as well. The use roles might get richer and deeper, and might support more processes and more scenarios. Tight integration with Microsoft Office, together with Web services enablement, will provide the possibility to use Microsoft Office applications as the actual frontend, in much the same way as Microsoft Dynamics CRM already uses Outlook. Also, introduction of contextual business intelligence, and integration with mobility platform, both of which have already been enabled to an extent, are the two areas that could go through considerable improvements.
Company + Ecosystem: Microsoft Dynamics NAV has a track record of providing great integration capabilities, and Web services in Microsoft Dynamics NAV 2009 are just the latest addition to the arsenal. With Web services in version 2009, Microsoft Dynamics NAV has just made the first steps on a Software + Services path. Integration with Microsoft Office is one of those features that get better in each version. Two of the best examples are Word and Excel export functionality through XML stylesheets, and fully customizable integration with Outlook, both introduced in version 5.0. With the Microsoft Office family growing in members and functionality, many enhancements can be expected in this area. Last, but not least, companies are doing increasingly more business with their customers and suppliers electronically. Future versions of Microsoft Dynamics NAV are going to bring a lot of enhancements in the area of collaboration and data exchange with business partners, something that has already been supported to an extent with the Commerce Gateway feature, but which can be expected to include more out of the box scenarios.
In this chapter, we journeyed through the world of Microsoft Dynamics NAV 2009, and all the bells and whistles it brings along. We discovered what makes it so special and so different from anything Dynamics so far. Then we covered the topic of implementation of an ERP system—what an implementation process might include, and what is important to know about implementing Microsoft Dynamics NAV. We went through the new architecture, and learned what Microsoft Dynamics NAV comprises, and what lies behind the RoleTailored client and Microsoft Dynamics NAV Service Tier (NST). At the end, we've taken a sneak-peek at the future of Microsoft Dynamics NAV and what we can expect to see over the next version or two. All in all, in this chapter we've introduced Microsoft Dynamics NAV 2009; let's now get our feet wet in it, and move on to the next chapter to meet the RoleTailored client up close and personal.