After a long time of iteratively extending the Dynamics Ax 2009 ALM tool, we can say that the first final and full deployment of the Dynamics Ax ALM tool in the production environment has been a succes. Our customer went live in the end of last year. More than 100 users and an IT team are daily using a Dynamics Ax environment where an Ax ALM tool supports their:
- Issues
- Business/Features requests
- Testing
- Resource planning
- Release planning
- Ax Module dependencies
- Ax Software development artifacts
- Ax Application building for each release
- Ax Bug fixing
- Ax Software solution deployments
- Detailed traceability from issue or request to solution deployment
At least two things that all these points have in common is their ease of use and the traceability that justify and allow an easy follow up on every activity or artifact. This is mainly made possible because of the deep integration with Microsofts Team System.
Next week Microsoft will introduce in the Ax technical conference 2011 their improvements in next version of Ax, and this also in the area of Dynamics Ax application lifecycle management. In some areas where we made specific ALM development to support our customer and general ALM requirements, we hope to see that Microsoft future Ax version will provide nice enhancements, partially based on Team System. We are looking forward to that!
For more information about the ALM tool please feel free to contact.
Application lifecycle management (ALM) can be described as an overall technique to provide and support a certain level of implementation, system and business qualities. For these qualities to reach a minimum level of satisfaction it requires a set of tools to ease the road to assur it.
Because a Dynamics Ax implementation environment has some gaps related to available tools supporting a high level of Dynamics Ax ALM, I want to describe here shortly the problems we face in my current project and others can face too and mention areas we are tackling with our own designed tools. With these tools and the standard available tools we try to support the enterprise in their attempt to setup a strong quality generating implementation methodolgy which incorporates ALM at a high level.
ALM tools in Dynamics Ax
The domains through which ALM tries to reach quality are: Requirements management, Feature management, Architecture and Design modeling, Project Management, Change management, Configuration Management, Build management, Testing, Release Management, Software Deployment, Issue management, Monitoring and reporting, Workflow… (see for more Wikipedia)
For the Dynamics Ax application there is a nice ALM toolset to support the domains but they are still in its basic/essential phase. Currently the toolset contains:
- Unit testing frame
- Best practice validation frame
- Version control frame (Team foundation server)
These tools and frames are mainly centered around the coding activity. Some others are:
- Data upgrade script management
- Reverse engineering (UML diagram generation)
- Upgrade reports
which leave more the realm of coding but are still far from providing very valuable implementation, system or business qualities through application lifecyle management.
Tackling Dynamics Ax ALM tool gaps with Team System
Currently the big tool from Microsoft that tackles a lot of these areas is Team System. Aspects as Requirements management, Feature management, Project Management, Change management, Issue management and Version control from Team system can be easely combined with the ALM tools in Dynamics Ax. Companies that have a solution based on Dynamics Ax certainly have an intention to fill up the ALM gaps in Dynamics Ax and build sometimes some extra little tools or use the above mentioned aspects of Team System.
Standard ALM tool gaps for Dynamics Ax
With the current state of the art around Dynamics Ax we still face some ALM aspects that can’t be supported relatively directly with available tools.
One important aspect for every architect is the validation of the Architectural requirements like eg module dependencies. These are certainly important to manage when you are building a product line or your application is in an agile environment that constantly demands changes. Dynamics Ax has no build in architectural validation tool and neither Team system can help in this area.
When additions for the Dynamics Ax application are required, the development mostly happens inside Ax projects. These are a grouping of application elements which the developer changes or creates for providing a solution. When the task of the developer is done this project needs to be deployed on other environments. Dynamics Ax tools don’t exist to ease and trace this Software deployment aspect or follow up relatively safely/accurately related statuses like accepted or task closed.
Traceability during the entire application implementation can help in providing quality on all levels. Traceability can be related to the evolution of the different Ax project builds that were deployed on all environments, to the application elements that were changed for a specific request, to the features or bug fixes that demand the development task… Standard Dynamics Ax tools don’t provide currently this level of Feature management, Change management and Issue management.
These gaps and others (Development task management, Application auditing/monitoring, Release management…) demand at my current project a solution. In the project we are setting up an agile development environment in which we try to provide an implementation base for the following years that incorporates a high level of ALM possibilities from the beginning.
Event driven architectures (EDA) will come in the following years more to the front in distributed applications and their architectures. Some think they are the next step after SOA, others have the idea that the 2 (reference) architectures complements. Eitherway, in todays distributed applications some concepts of EDA are already used, although mostly the defined/used software delivery cycles don’t position them very explicitly in a good structured quality generating delivery process. Contemporary SOA is becoming a mature technique and a new standard in enterprise architectures. The possibilities are that EDA undergoes the same and delivers some extra or other quality characteristics than contemporary SOA. It can bring the continuous seek to unification intra and inter applications and/or enterprises to a new level. What EDA certainly shall do is bring our designs closer to an inherent attribute of nature: send and move on.
The Dynamics Ax performance team published patterns that can be interesting to solve performance problems in case maybe some of the following issues arise.
Issue #1:
The #CurrentList macro is used for both SysLastValue and Pack/Unpack serialization.
Issue #2:
Non-packable objects are created on the dialog which runs on the client, but used on the RunBase derivative class which is running on the server.
Issue #3:
Client interaction is being performed in the main method.
Issue #4:
Significant server interaction is being performed on the Dialog or in the dialog method.
Issue #5:
The RunBase-derivative class needs to load data from a user-specified file that exists on the user’s client machine, but the class’ run method will be executing on the server.
In this paper they describe one general pattern and some specific patterns.
Dan Rawsthorne wrote an interesting post about “Scrum is Effective, not Efficient“. I don’t follow fully so i made some comments. I write it here again because it has some aspects that are related to software architectures and which are important to produce quality. To have the full context of this post it is important to read Dan’s post.
Dan says: “The more feedbacks you have the more effective you’ll be… “
I think the amount of feedback is not so important to determine the effectiveness, what is more important is the quality of the feedback which is aligned with business goals. Can’t a few good feedbacks be enough to know how effective you are? You can specifiy some quality scenario’s for measuring your effectiveness. Ofcourse lines of codes or function points are to vague and don’t tell much business/product relevant effectiveness. Thereby, finding the right feedback through quality scenarios can help to reach the effectiveness efficiently instead of going for a lot of feedback.
Maybe it is not easy to specify precisely what needs to be done, this is where agility comes into the picture i think, but in general every project has some clear business (case) goals and for those, quality scenarios can be provided to measure the overall effectiveness.
Dan says: “In order to be efficiently agile, you would need to have feedback loops that got you the answers you needed as fast as possible, and have as few feedback loops as possible. And we don’t know how to do that, now do we?
If you can specify how to be effective, and you say that agility is effective it means you can specify effectiveness, than you can specify a way to reach it efficiently. I think too that agility is effective and i would measure it with quality scenarios. This also gives the possibility to have a reduced set of feedbacks related to the Q scenarios and allow us to get there efficiently because we know our goal.
Dan says: “…if you can’t produce the right product every time (or virtually every time) then don’t start adding efficiencies to your process.”
Why can’t you add efficiencies in your inspect and adapt cycles? Rethinking and implementing the way to produce a powerfull effect can also ask for incorporating some efficient steps.
Dan says: “waterfall is efficient — agility is effective”.
I think if you say it is efficient, it means that it also has to be effective. Saying something is efficient means its result is effective. So in the conclusion it sounds to me that waterfall is the ultimate way to go, which i doubt and probably also not the one of Dan.
When we are in a situation in which we need to integrate an Ax module with other Ax modules, or the Dynamics Ax application with other applications some solutions arise and some considerations need to be made.
(Some comparisons are made between the AIF and the AMM but with no intention to fully clarify the differences.)
One solution is the Ax Messaging Module (AMM). Generally speaking it tackles integration on a fine scale.
- Ax modules can be integrated without direct knowledge of one another and without predefined processors or processing types (sync/async).
- An Ax module can be integrated with other applictions like MSMQ, Biztalk, or … also without direct knowledge of one another and without predefined processors or processing types (sync/async).
- A class message definition is the core definition for integration. A message doesn’t need to be mapped with a business enity. It can be of any type: a full customer entity, a processing status, an execution command…
- When message handlers process a message and an exception occurs, an exception message can be send just like any other message in the AMM. Because all kinds of message handlers can be subscribed to exception messages the exceptions can be brought visible easily.
All these aspects show some light weight characteristic of the AMM and put it in a strong position to provide a uniform way to introduce the messaging concept in the Ax application and cross applications.
The Application Integration Frame (AIF) also tackles integration but in a more coarse grained way than the AMM.
- The focus of the AIF is mainly on providing and consuming services between applications like MSMQ, Biztalk, Web service providers…
- Compared to the AMM: Integrating different Ax modules with loose coupling is not easy in the AIF. The focus of the AIF is on application integration.
- Services that Ax modules provided can be called from x++ in a strong coupling manner.
- Compared to the AMM: In the AMM no knowledge is required of other modules. The business logic of other modules can be called in a very loose coupling manner.
- (Document/Web) Services are responsible of adding, deleting, quering, or changing data in the Dynamics Ax database. A table is the core definition for integration.
- Compared to the AMM: In the AMM the core definition for integration is a class instead of a table.
- AIF provides an easy way to provide quickly (no coding) services for other applications so they can do CRUD operations on the Ax tables (enitities).
- Compared to the AMM: The AMM provides no quick way to do these operations on tables. The AMM is a frame where tables are not positioned as important data containers, classes are. Providing those services requires coding them for every table. Delivering data of one or more Ax tables (mostly business data) to another application is in the AMM less flexible than the AIF.
- In the standard Ax package the focus of exchanging data is on business entities. This is the most important data of a business to exchange between applications.
- Compared to the AMM: Any data that needs to be exchanged can be exchanged inside or outside Ax easily with the AMM without using tables and so table operations.
The post about Event Driven Architecture describes how events (messages) can be seen as extensions of services. In the same way the AMM can be seen as an extension to the AIF. Although AMM certainly doesn’t replace the AIF at all. It is just a different way to tackle problems and so with different design characteristics. With the AMM a shift is made from tables as the main data containers (AIF) to classes as the main data containers (AMM). The message data in the AMM is not data that essentially is required to be queried. In the AIF the data are mainly business entities which probably need to be used at different moments in time and for maybe different business processes. In the AMM it are just messages with a short life span, with in its essence no intention to have its data to be stored for flexible querying. The AMM is a frame for carrying messages and processing messages, like the temporary messages in our nervous system which carry information and initiate activities.
For those among us who wants to bring the architect’s mind more explicit into projects, Microsoft published very interesting information about how they see what architecture means in their world and what the architectural aspects will be with/in the cloud:
Event Driven Architecture is brought into attention in the (latest) Microsoft architecture journal 17 and more specifically in the article: Using Events in Highly Distributed Architectures. David Chou points out that SOA can be nicely extended with the event principle and gives some extra general quality advantages provided in the application when using events (others are described here in the context of the AMM) :
- Effective data integration
- Reduced information latency
- Enablement of accurate responce
- Improved scalability, managebility, reliability, flexibility…
- Improved business agility
When we look to the Dynamics Ax messaging module we see that it fits in the EAD as the intermediary flow manager (message broker). It propagates events in the Dynamics Ax EPR system to modules (partially) isolated by separation of concern and to applications outside the system. Also events from outside Dynamics Ax can be propagated to modules inside the system.
The events outside Dynamics Ax can use the SOA communication infrastructure or any other infrastructure. Inside Dynamics Ax all events are event objects in the object oriented architecture. The mapping of event formats and the propagation of these events is done automatically in the message broker with the use of the necessary channel adapters.
The team who developed a Linq provider for Dynamics Ax commented today on a previous post and announced their product features and their new blog. Because I can only fully support every step forward in better quality providing techniques and tools 
I want to explicitly point out here their comment.
Over the next few weeks we will be launching a blog where we hope to demonstrate some of the cool features of the product, as you point out it makes integration with Ax super easy.
Some features of the provider; Follows the Linq to SQL model, exposure of the Dynamics dictionary via .Net objects, VS ‘AxMetal’ Addin for generating the data contexts, Create, Update and Delete support for single and multiple row instances, full support of Ax transactions and of course retrieving data via the Linq syntax.
If anyone has any questions about the provider then please feel free to contact me.
Jonathan
If you want to download a trial version you can find it here. In my current project at AWW the use of the product is on the table for (future) evaluation.
Advanced Ax Batch is a nice batching frame for Ax 3.0 and Ax 4.0 with some very interesting design goals:
1. Remove the need for a running Dynamics Ax client. Job execution is service based with better security and the ability to run in the background.
2. Increased stability by integrating Ax with the powerful built in windows scheduling service (Scheduled tasks). The integration is based on Windows communication foundation (WCF).
3. Deep integration with the event log. This gives the ability to monitor the scheduling system with event log monitoring systems.
4. Performance counters ads the ability to monitor the health of the system.
5. Manageability. Configuration and setup is Ax based with seamless integration of external services.
6. Job sequences. Execute a batch group or class depending on the result of a previous steps.
7. Highly extensible event system adds event monitoring to the job scheduling system.
8. Reduced cost by using Com users instead of regular Ax users.
9. Advanced notification through email when a job succeedes, fails or times out with detailed information from the infolog and eventlog included in the mail.
There is also a demo.
My LinkedIn profile 
