Empowering your users with reference data and knowledge
Before joining Microsoft I worked in consulting. We worked hard searching for only the most talented consultants and account executives (salespeople). We'd look for individuals that could share our culture and passion for customers, but also those that were capable of working on their own, without handholding. New account executives (AE's) and consultants would learn the type of services and types of customers we were looking for, along with the way we conducted business. Each day AE's would get an updated copy of the consultant availability sheet; a spreadsheet of who's on the bench, when projects were expected to end, vacation schedules and when new hires were scheduled to start. Quarterly we'd roll out new service offerings, with updates monthly. Because of the breadth of our offerings, some AE's would specialize selling certain services, and our consultants were diverse, but fell into certain disciplines. In other words, we partitioned the overall data to individuals and their tasks.
With this business knowledge, and reference data, the AE's were empowered to go out and close deals. AE's would meet with many customers. Of 100 customer meetings, they might close a handful of deals; and by industry standards, that's a high ratio. On a good day, two AE's would close two different deals. It's possible they may have even committed the same resource. Another AE may have committed a specific consultant, let's say Ross to a unique opportunity. Imagine the AE returns to the office and informs our sales manager and director of consulting services of the new deals. However, once they "submit the order", and "validate" the order, they realize they have a "conflict". Ross can't go to that customer because of a non-compete clause for the next 3 months. They resolve the conflict by doing a bit of shuffling and both orders can be accepted.
Now consider a "connected" system approach. Rather than spending the time and resources finding "smart" AEs and consultants, we take anything with a pulse. Rather than relying on their intelligence, we give them a cell phone, a laptop and a car. The sales person, let's call him Earl, is told to travel to customers and sell, sell, sell. As the customer asks a question on one of the service offerings, Earl says hold on, and calls Susan, the sales manager. The phone rings, but Susan is finishing a call with another salesperson, but Susan multi-tasks and puts the other call on hold to answer Earls question. For some reason, the customer is used to this "dumb interface" and decides to buy the services anyway. Earl now needs to call Heather to confirm who's available. Heather is in a meeting with Joe and Steve trying to plan out training for the new service offerings. Heather takes the call and commits some resources and goes back to the meeting. Another salesperson calls with a "huge deal". Although it's a bigger deal, Heather just committed the only qualified resource to Earl, so now she needs to either pass on the bigger deal or move some consultants around. By the time she juggles the consultants, contacts the salespeople that are meeting with customers, Joe and Steve weren't able to get the future planning done as they were busy answering the phone for consultants who couldn't figure out problems on their own.
Now, it's fairly obvious the "connected sales force" doesn't work in this model. It's not that we haven't seen consulting companies, or other industries try the "dumb interface", but it rarely works. The major difference here wasn't that conflicts were easy to avoid. The difference is enough business was generated to cause a conflict. You can have the most perfect, accurate system in the world, but if customers don't come, does it matter?
So, how does this relate to development? Layered business logic. The AE's had enough business logic locally to pursue customers. The deals were "revalidated" as they were submitted. As they're submitted, additional validation logic was performed. We continually hear from customers they must have stored procedures in SQLce, or it's just not a real database. Aside from us not wanting to expand the size of the nice compact database engine, or the code free file format, I'd ask, do you really have everything you need locally to run the exact sproc locally? Do you really want to burden the local machine with everything the server needs to complete the operation? Or, like the AE's, do you want to give them enough info to empower them to make smart decisions. It's not that AE's aren't extremely talented. But, rather than know how to manage consultant personal issues, or process back end credit card transactions, manage inventory allocations, they can use their local resources to deal with customer relationships. In my example above, Susan, Heather, Joe and myself had another level of detail we needed to worry about. If we had to deal with every detail it takes for the AE's to close a deal, we'd never get our solutions or delivery issues resolved. The same holds true for those servers back at the office. Shouldn't they be managing the things that only they can handle? Servers are easier to come by than solution directors, but is that smart business. Just because you can, doesn't mean you should. Rather than throw more "resources" at the data center, why not offload the work to the clients. By embracing this model, you can actually simplify your development efforts.
We have the raw components needed to do this today. It's not that different from the way other business aspects are managed. Even in a connected world, it's not practical for every resource to be available at the same time. And, even if it was, would the world be in a constant deadlock as every user attempted to complete a long running transaction to book a hotel, rental car, show tickets, meals, gas, airline tickets, baby sitter, etc. The world runs today because of buffering, artificial stability, queuing, and caching resources. Today, in Visual Studio 2005, we have a number of necessary building blocks. We have more coming in Visual Studio Orcas. Here's a few:
- We can use assemblies to package up common business logic. We can even derive sub classed validation objects that run on the server with additional resources.
- We can use Sync Services for ADO.NET to synchronize reference data to the client. You can use Sync Services to send updates back to the office, or submit completed operations via services with something called logical queuing. I'll write about this in an upcoming blog post.
- We can use ClickOnce to update the business logic and overall application flow to easily update our clients with intelligence.
So, building Occasionally Connected Applications is how all scalable systems work. Why do we think software should be any different?