The thing that sets one business apart from another is the special added value that it brings to the table. It does something different. It has come up with an idea that no one else does quite the same way, or so the business believes. Even when someone else is doing exactly the same thing, the thing that differentiates the two is the way that they do it. This is the "special sauce" that makes a business special.

 If this recession has done one thing, it has forced companies in corporate America to take a long, hard look at their relationships with their customers, and many companies are realizing that they need to be far more proactive about their relationships. 

But how do companies go about finding that "special sauce?" And more importantly, what can they do to maintain it?

While I don't believe for a second that all the special sauce in the world comes from technology, technology can often be at the very heart of making that special sauce, especially when we are talking about building customer relationships. At the heart of it is showing the customer that you understand them, that you care about them, and that you want to retain them as a customer.

Technology can be a huge support in this area, and that's where research and innovation come in. Using technology to build better business relationships is where the focus of technical growth is, and learning how to apply technology to do so is where research and innovation come in.

How to look at this

When I started work on the Microsoft Exchange Integration project, my first goal was to understand what the business was trying to do. In this case, it was keep better record of appointments that were set up with the customer, and monitor changes made to those appointments to ensure the best customer experience possible – a really simple requirement.

Once I knew what the requirement was, the next step was determining a) how to provide it, and b) what else I could do. In other words, I stepped back a level and looked at the big picture to strategically improve the interaction between sales and prospects. Rather than just answering the immediate requirement, I decided to look at how I could improve the overall experience.

Among the things I immediately realized was that not only could I provide a way to allow users to create appointments in Exchange, but I could also keep those appointments up to date on the database side. Not only that, I could even go as far as to allow users to query their own availability from within the application.

My next step was to figure out what I could really do with the technology, and this is where the real research happened.

The real research

Research is not just a technology thing. As a geek, I am inclined to look at the code and say, "Wow, that's cool." But realistically, an Enterprise Architect's job is to look at the business and understand how to improve the business by applying technology, and the first step is to understand the business, not the technology. So my first step was to walk through with the customer what his existing process looked like and where he wanted to optimize it. In other words, the real research was into understanding what he is trying to accomplish by improving his business process.

Sometimes when you are buried in a process on a day-to-day basis, it is really hard to recognize anything but the pain of the process. The reaction is to fix the pain, rather than the process. What often happens is that an outsider is able to look at the process and say "Why do you do that?" and make the process owner re-evaluate the process completely. Many times, the process is the way it is because it has always been like that.

So the real research is about finding a way to simplify and even eradicate process. What people often fail to grasp is that processes change over time. As systems become more automated, there is less and less need for the duplication of effort that goes into some processes.

Looking back at the Microsoft Exchange Integration example, not only does the process owner need the ability to monitor the appointment changes in terms of how often an appointment is changed, but he also needs to be notified when the number of appointment changes is exceeding acceptable thresholds, or (and this was not factored in initially) too much time has elapsed between the initial contact and the expected follow-up. Remember – we are dealing with a prospect. Prospects go cold if they are not reminded of their interest.

That last point made me think of something else. There are times when a prospect has to postpone appointments because of business pressures. Heck, I blew off a guy last week because I am so snowed at work there is not time to see him, but that does not mean I am not interested in his product. Right now is just not a good time. Of course, I am likely to forget about him, so it is in his best interest to follow up with an e-mail or something that reminds me that I was interested in his product. Don't pressure me for an appointment. Just remind me about the product and its capabilities – something like "Our product just helped this customer achieve this business objective. You may be interested in reading about it."

Notice that these are not part of the initial requirements, but based on my own experience I can think of about 20 different things that the process owner could do to maintain the prospect's interest and further the sale.

So as I was researching this, it occurred to me that the process owner would benefit from automatically being able to pass on useful information about his product to his prospects that have not had any communication for a period of time. That nudge may trigger deeper interest. This made me realize that the process owner could really benefit from a knowledge-base type application of customer experiences that could be formatted and e-mailed.  

Another thing to notice about this is that before I ever looked at the technology that I was about to use, I first considered the business problems I was trying to solve. Thoroughly researching the business needs is absolutely critical to providing a valuable solution.

Takeaway #1: The thing to take away from this is that, as an Enterprise Architect, researching the business process, how it works, and what executive management's objectives are, is way more important than the technology research. If you do a thorough job of the business process research, it allows you to focus the technology research.

Researching the technology

Of course, as a geek, there is nothing that I love more than trying something completely new. I can spend hours messing with technology and trying new stuff. In fact, one of my greatest weaknesses is that I enjoy doing new stuff so much that I have to really force myself to finish things off. So when I get to mess with technology for the fun of it, I am in my element.

As I said, though, the important thing with technology research is to have a goal in mind. Why are you looking at the technology and what do you think you can accomplish by messing with it? What real business problem can you solve with it?

With the Microsoft Exchange integration project, a lot of those things were very clear from the minute I had the business problems clear in my head, so the next step was to understand the technology. My first step was to understand what Microsoft provided and it very quickly became clear that the Exchange WebServices (EWS) API was their new direction and I had to take this direction. Cool. Now I had to understand what EWS could do. That was mostly a reading exercise to understand it from Microsoft's point of view, and their is a very informative forum on Microsoft's site where you can get an idea of some of the problems people have faced.

Of course, Microsoft does not have all (not even most) of the answers. Here's where I cannot possibly imagine life before Google. Most of the posts on the Microsoft forums are by people who have spent way too much time drinking the Microsoft Kool-Aid, not least of which are the people over at the MSDN "All about interop" blog who make this inane statement: "While I love .NET, not everyone has seen the light! and some poor developers are relegated to using Java even for new applications."

OK, you brain-dead numb-skull! Let's see you try any serious Unix development in .NET. Yeah, Mono is there, but Microsoft doesn't even support it. Unfortunately, for every brain-dead Microserf, there is an equally ritalin-deprived Javazoid who is so bigoted that he cannot see the forest for the trees either. There is absolutely no place for technology bigotry like that in real Enterprise Architecture where the technology is definitely secondary to the business needs. 

I knew most of my work was going to be Unix-based and I knew that I was not going to find anything that was OpenEdge-related, so Java was the obvious other platform to use to talk to Exchange. A quick Google search of "exchange web services java" turned up a number of hits, but the most valuable one was undoubtedly Reid Miller's blog.  He did a really good job of walking through the process of connecting to EWS from Java, and without it I would probably have torn my hair from my skull in chunks.

Google also referred me to a web-site that sells two products called EWSJ and JEC. These are Java-based libraries, one of which makes a connection to Exchange Web Services. The libraries look very promising, but there were several reasons why I did not like their solution, not least of which is the fact that I need to connect to Exchange Web Services from OpenEdge, so this was not going to solve my problem.

One thing that I learned that has proven to be unequivocally true is that NTLMv2 authentication, which replaces NTLM authentication on Microsoft Server 2008 R2, is really tough to do in Java. From what I can make out, there is a way to do it if you buy a third-party library, but I have not proven that the library works and I am not sure that it is warranted. This helped me make a very important decision long before I started writing any code. Instead of fighting the Microsoft authentication battle, I would rather sort that out later and use digest authentication from Java to EWS. 

Another very valuable thing that I did was buy the book. As I said in my original post on the Exchange Web Services project, Dave Sterling, et al's book on Microsoft Exchange Web Services is invaluable and it taught me so much stuff in so little time that it was worth every cent of the $40 that it cost me.

A clever man learns from his mistakes. A wise man learns from others' mistakes. - (My grandfather, Eric Frank Brading – 1926-2008, one of the wisest men I've ever known)

Takeaway #2: Spending a few hours digging into what others have done can save you a ton of trouble.

At last – Try it out

My last step was to try out the code. Within 2 hours I had a connection to EWS working from Java. An hour later, I had it exposed as a WebService, running on a CentOS box in a Glassfish V3 application server. Ten minutes after that, I had OpenEdge calling the Java WebService to talk to EWS. So four hours of experimentation got me the working prototype to create appointments in Exchange.

Note that my focus was to meet the business requirements in what I was doing with the prototype. I tested to prove that I was able to do the main thing that my customer was asking for. Sure, the code is ugly, but who cares? It's only for testing.

The next step was to prove that I could listen for messages from Exchange. In other words, I needed to get the notification API working. This was a little harder because I was hoping to get the communication to go through an OpenEdge AppServer. EWS expects a specific format and I could not get my OpenEdge service to meet EWS' requirements. This is where you have to make some early decisions and here's another takeaway:

 Takeaway #3: Fail early. If it's not critical to business success, don't waste your time on a perfect technical solution. Learn to compromise and come back to the imperfections later.

Absorb the results

Once I got the notification API working, I spent some time building some test code that would demonstrate performance. Now you may wonder why I was worrying about performance so early in the cycle. Here's why: Performance is the most misunderstood concept in the computer industry. Understanding latency and where the potential bottlenecks are early in the cycle will change the design of your application. Instead of building unnecessary complexity because of irrationally anticipated performance problems, hard, cold, data allows you to make a more sensible decision.

Another point to bear in mind is that as you experiment with it, you will learn a lot about the underlying technology. Save your results away because questions will crop up later that you can always go back and re-test, and this brings us to the next takeaway:

Takeaway #4: Your research is always going to lead to more questions than answers, and sometimes you will only think of the questions later. Make sure you keep all your research so you can always refer back to it.

For this reason, I check all my research code in to my source code repository and I comment it like I would commercial code so I can always go back and figure out what it taught me and how I was thinking when I wrote it.

And now for the innovation

As you absorb the results of the research, you will quickly see things that you can do with it to apply it to the business needs. One of the things that hit me very hard is that I can now synchronize the contact list in Exchange with the CRM system so that the contact list can be more accurate. I also realized that we could build a monitor for an e-mail address so that we can automate the processing of e-mails as they come in to things like the Sales alias. I could automatically create a prospect and generate the information a sales person needs to react to the prospect.

To really innovate, step back from the technology, look at the real business needs and figure out how you can do something that will radically change the business. For this project, that will come from exposing the whole API to a service-oriented architecture that is founded on a solid middleware solution. This will produce a mass of events for the business that can be used to make real-time business decisions based on very valuable real-time information.

So our last takeaway is:

Takeaway #5: When you are considering how to apply the technology, step back from the code and look at business problem again. Look at the objectives that the business has set and make sure that what you are going to recommend will deliver outstanding competitive advantage.

After all, that's the secret sauce.