Value Mapping (Flattening) Functoid Troubles

A while ago I was troubleshooting a BizTalk solution my company created. This solution facilitates the communication between a CRM front-end and a commonly used municipal back-office system. I had not created this app, so it took me a while to figure out what the problem was. The trouble was that something went wrong in one of the maps. Some messages that went through the map were correctly processed, while others weren’t. Here’s the map (click to enlarge):

The map's functionality

The map transforms a response of the back-office to a message format the CRM system understands. It’s quite straightforward; the input schema contains a root element that in turn contains one choice element. The options for the choice element are three (although one of them isn’t used, don’t ask me why) tree structures that are the same, except for their names. Scripting functoids are used to concatenate some fields (and do some other stuff) from the input message and the result is fed to Value Mapping (Flattening) functoids. These functoids have two input parameters: the first is the result of a Logical Existence functoid that checks the existence of one of the choice elements, the second contains the concatenated values of some fields. The result of the Value Mapping (Flattening) functoid is the second parameter if the first one is true. So to summarize, the map checks the existence of the choice element options and when the element exists maps the concatenated values of some fields in this element to the output message.

Problem

The weird thing was, that only messages with the BinnenVerhuisaanvraagResponse element (excuse my dutch) were mapped correctly. When a message contained an UittrekselaanraagResponse element, the output message missed the mapped fields (should be in the InputData field of the output message). This was very strange, because the messages were identical, except for the names of the choice element options. Also I double-checked the functoids, but they were again the same.

The Value Mapping (Flattening) functoid

What had caught my attention briefly earlier was the use of the flattening version of the Value Mapping functoid. This version flattens a tree structure input to a single field. The input of these functoids in this map however is always a single value from a Scripting functoid. Maybe the reason was that in an earlier version the Scripting functoids weren’t used, but the input fields directly, but that’s just a wild guess. Anyway, in this case there is no need for the flattening version of the Value Mapping functoid. So I replaced these with the normal Value Mapping functoids, ran some tests and hey, all messages are processed just fine?! I could not find anything on the net as to why this happened, I might have stumbled on a bug here, although I have not tested this error in other environments. So, be aware of this when using the Value Mapping (Flattening) functoid in source schemas containing choice elements!

Avoid the alignment trap

I stumbled upon some very interesting research by Bain that studied the link between getting IT right and the result on business growth and performance (via InfoQ). I’ll summarize the Bain study hereunder and give my thoughts on it.

Results

One of the results of the study was that while some companies reached performance gains by using IT, other companies get stuck in what Bain calls the “alignment trap”. A company is in an alignment trap when increased investments in aligning IT with the business actually hurt growth and performance. IT becomes an obstruction in stead of an enabler. Costs are higher than expected and projects take longer to complete, if ever. There is an over-alignment that causes high fragmentation, redundancy and low scalability.

The solution to get out of the alignment trap Bain proposes is getting effective first and then getting aligned. This may involve temporarily getting lesser aligned to be able to provide more effective solutions. Unnecessary complexity should be avoided, IT capabilities should be, in Bains words, “rightsourced”: the right capabilities should be sourced, from the right source, from the right shore, at the right cost, and the quality of IT delivery should be high.

Only when high effectiveness is reached it is time to get better aligned. Business strategy should be supported and enabled by IT capabilities, IT investments must be made in the right place and business results must be monitored, and both business and IT accountability should be ensured and clear.

Bain research results

SOA

I have seen my share of IT projects trying to bridge the alignment gap before effectiveness is reached, especially in SOA environments. This might be one of the most important reasons SOA attempts fail. Although a service oriented architecture removes redundancy by creating reusable services, there are problems that must be dealt with before improving alignment. One of these problems is creating a good technical foundation upon which all future services can be built. I am not talking about problems like choosing what constitutes a service, what granularity to apply, getting business support and commitment; these are alignment issues in my opinion. I am talking about building a performing, not overly complex, technical foundation, or architecture so you will, using IT capabilities from the right source that effectively enables the creation of value adding services. I have seen companies building an architecture and then quickly moving on to implementing value adding services on top of this architecture. On the way flaws and design errors of the foundation are found and fixed, often resulting in adding complexity to the same design. Another complexity issue is the fixed choice for a specific platform and/or product a company enforces. This product must be used, even if it adds only complexity, not value. Performance issues arise, integration problems prevent implementing business scenario’s, etc.: IT has become an obstacle.

Lightweight 'Guerilla' SOA

The design of the SOA foundation could be Big Design Up Front, something I would not advocate for developing a business service (apply agile methodologies there), but pay attention on keeping complexity low and effectiveness high. Try not to create barriers, like performance bottlenecks. This does mean designing and measuring for performance. I’m not a fan of premature optimizations, but this core technology determines for a great deal whether the SOA/IT is a business strategy enabler. I know you cannot anticipate everything beforehand, but I agree with Joel Spolski that thinking things out in advance can reduce the chance having to solve a non-functional issue in an established architectural landscape. So, my advice is: first get effective by creating an enabling foundation, secure non-functional requirements and keep it lightweight! When that is in place, agilely create value adding services. Of course, the technical foundation is not a static thing, it should evolve to keep enabling business strategies. Create a Guerilla SOA. This might seem controversial to my advice of designing up front and creating a solid foundation before delivering business processes, but it isn’t. Designing a lightweight foundation up front may take more time than jump-starting an increasing complex, heavy-weight middleware solution (although often this takes more time and money), but a clean and lightweight foundation is more manageable in the long term and keeps being an enabler.
This way, IT should result in increased business growth and performance, while getting costs lower.

Gaining Advantage By Letting Your People Go

Tags van Technorati: competitive advantage,strategy,employee turnover

Currently I'm busy writing a thesis for my master's on the relationship between knowledge management and sustained competitive advantage. Taking the perspective of the resource-based view I try to find emperical evidence that firms using unique knowledge will perform better than their competitors. The past months I've been reading a lot of scientific articles on the subject, most of which, though some are dated, were very interesting. Some of this stuff I like to share with you.

People quit

Besides reading scientific articles I also read a fair amount of blogs. A while ago I read an interesting piece about employee turnover in IT by Alex Papadimoulis of the dailty wtf fame. Alex argues that employers and employees should face the fact that someone won't work for the same boss ad infinitum and be comfortable with that. He even thinks that embracing this fact will be beneficial for companies for three reasons: employees leave with a positive attitude and their they have not engaged in less productive behaviour, an alumni network is created and unskilled personnel is flushed out.

Paradox

This is a really interesting point of view that unveils a paradox. Making it easier for employees to leave the firm increases the risk that valuable knowledge is drained from the firm, since the knowledge assets a firm owns mainly reside in the people that work there. When you see knowledge as the most important source of competitive advantage (as a lot of scholars do), this means that advantage might decline or even disappear when this strategy of embracing quitting is used. So, what should an employer do?

Building a network

I think that acknowledging that people do not stay forever is a good thing, but to put this inevitable fact to their advantage, firms need to take action. An alumni network builds itself, but organizations need to actively put the network to use. A great example of a firm that does this is ThoughtWorks in my opinion. Not only do they display blogs of their employees on their website, there is also an alumni section. ThougthWorks' current and ex-employees stay in touch, read eachother's blogs and so share knowledge. ThoughtWorks has created a network of ambassadors and champions consisting of both employees and alumni. Another example of a company that endorses employee transfers is Toyota. They often let employees transfer to their suppliers, sometimes permanent and sometimes temporary. This way they can build a network identity and share knowledge within this network. Both Toyota and their suppliers benefit from this approach.

Minimizing risk

The risk of losing valuable knowledge can be minimized in a few ways. First, a lot of knowledge is context specific and loses its value outside the firm. Also firms aquiring knowledge by hiring away personnel face adjustment time and consequently can't put the newly acquired knowledge directly to use.

Second, a lot of knowledge isn't articulate. This tacit knowledge, as it's often called, is problematic to transfer, because it can not be documented or codified. It requires face-to-face interaction to be transfered. It will not leave the firm quickly, but it is also difficult to transfer within the firm.

What to do?

So what companies should do is integrate the knowledge of their employees, making it more context specific and creating collective, organizational knowledge instead of individual knowledge. Although the trend is to document and codify all knowledge in the organization, firms should leave some valuable knowledge tacit. Which knowledge to keep tacit is a key question. When specific knowledge needs to be transfered within the firm, it should be codified, or externalized to be able to speed up the transfer. But beware, speedy transfer could mean speedy disappearance!

Letting people leave the firm in a good way, building an active alumni network, while at the same time keeping valuable knowledge inside the firm is in my opinion a way to gain and sustain competitive advantage.

Welcome to this blog

Hi and welcome to my personal space in the blogosphere. I am a software developer specializing in Microsoft technology at a global information technology services company. My interests lie mostly with Enterprise Application Integration using Microsoft .NET and BizTalk. I am always trying to stay on top of new technologies, which at the moment are WCF and WF.

I live in the Netherlands, somewhere near Amsterdam. Besides my day job I'm currently obtaining a master's degree in the social sciences. The programme I'm taking is Policy, Communication and Organization at the VU University Amsterdam, where I study organizations from different perspectives using theories from sociology, psychology, public organization, business administration and strategic management.

On this blog I will post about these two passions of mine and try to combine them. So when I write about new technology I'll try to explain the business value of it. When I write about organizational issues I'll try to relate them to my daily work and potentially that of many other developers out there. Stay tuned!