- I've decided that I finally really give up on stored procedures
-
As much as I want to play the game and use stored procedures for data access logic, time and time again I run into yet anothe rissue where I get bit. I've always pushed back on developers who want to use stored procedures for any number of reasons. There's a great list of reasons here. This time it turns out not to be the usual reasons - this time it's much simpler: there's really no way to make the whole deployment story scale in any way. As soon as you have more than one database (i.e. a multi-tenant application hitting a "private" database) you WILL run into a problem when you need to fix the always present data access bug.
Ugh... why can't I have a single place where I can put all my data access logic? Like, maybe, just maybe, a shared database holding no structure, only proc definitions? Or, maybe a DLL. Yeah, that'll do it, I'll use a DLL with dynamic SQL.
- Too funny
-
Yeah, yeah, I've been really quiet for a really long time. I know. I'm sorry. But, I've been busy with my new venture in MSR. I can't talk about much of it right now, even our internal email messages go through DRM. Let's just say that I've been having fun with hardware (ya know, soldering and stuff), embedded systems (not CE), and lots of toys.
Anyway, the point of popping my head up is to try to figure out why the sudden increase in CRM-related traffic into my inbox. Seriously, it's like I started over or started posting a bunch of interesting things about CRM. It's been a long time - I left when we were just thinking about what CRM V4.0 was going to look like under the covers (and it even looks like I thought it might). But nothing since then. Anyone else have any idea why I'm suddenly popular again?
I'll post a lot more information about my new project in the coming months and may even start posting stuff about the group I belong to independent of that.
- GP's been drinking the Kool-aid again
-
I really respect GP's opinions on a lot of SaaS-related issues, but this one might be pushing my boundaries a little bit. GP is starting to confuse a rich client experience sitting on some "free" cloud storage as an S+S story. I don't know about this. It's a very small step from storing a document on a file server somewhere, anywhere. The only difference is that the "save" API used is slightly different.
Now, if something happened to GP's document once it was stored, or even better, while he was editing it. And that something happened because GP had signed up for a cloud-based service that added value to the client, then I'd have to say have another sip. But, this is not what I think of when I think of S+S (disclosure: I'm not part of the DPE organization that truly believes in S+S and I'm no longer part of the MBS organization that wanted to believe in S+S).
The "light-up" scenario just doesn't cut it for me. I want SaaS - either the stuff runs in the cloud and that's my primary interaction point, or the cloud is completely indispensible like in IM, or we finally start building service-oriented applications where stuff just runs and the fabric figures out where things happen. But, saving an Office document to a SharePoint site? Not so SaaS.
- Not surprising, but I have nothing to say
-
It's not going to come as a surprise to anyone who used to read my blog and has noticed that it's been very quite. I realized that I really have nothing to say when I'm not working on a project that I can say nothing about. I have been working on a few interesting projects over the last two years, but neither one is something that I can publicly discuss. I've found that makes keeping my blog current particularly difficult.
I'll try to keep writing here as I move on to my next project - which is again extremely MSFT-only at this point. Hopefully I can find a way to talk about the different ways we're solving general problems in the space without giving away what it is there we're actually going to work on. How's that for promising and saying nothing.
Wow, just sitting here trying to explain why I have nothing to say is hard. I wonder what's happened that I'm gotten quiet. Weird...
- SaaS: Collaboration
-
Yesterday I set the stage for the 5Cs of Saas: collaboration, community, connectedness, completeness, and changeability. Today I'm going to focus on collaboration in SaaS. As I mentioned yesterday our team found, through customer interviews and research, that a motivating factor - one of the primary factors - for SaaS purchases is to allow seamless collaboration between parties in arbitrary (but well-defined) roles.
Well, what exactly does this mean? From our perspective it means that an actor using the software has full, role-specific privileges and experiences directly within the software. That is, there's no concept of a "portal" or any other external "connector" to the software. It also means that the provisioning of that experience is seamless to the actor doing the provisioning.
An example here might help explain this. Let's say we have a customer support representative using a customer service application. This person receives a phone call or other trigger causing them to describe a customer to the application. Now, in a typical application, this means that there's a user, the customer service representative, and a customer. These two concepts are typically quite distinct in their semantics. The user has access to the application and, by definition, can use it. The customer is a data point somewhere in the application represented by a row in a database, but has been granted no additional rights.
In a collaborative world this model breaks down. There's a distinct difference in the caste model: in some way the user is a higher caste entity than the customer. The user can create new data items and fully interact in business processes. The customer is disconnected from the application and may be able to "interact" via some external connector (for example receipt of an email message or a message exchange).
What we found was that our customers want us to remove this divide. They want to see the customer as a first-class, privileged actor in the application. But, and this is important, they do not want the customer to be a user in the application in a way that either uses a license or requires a specific provisioning step. As you might see we have a bit of a dilemma here. Most business software written to date enforces this divide. We can't use the existing models.
What can we do about this? Well, we could fake it and create an additional layer on top of the business application which provides some level of interaction for the customer. But, this means that any customization that takes place in the core application must be duplicated in this additional layer. It's not only that, but any business logic or business process which is enacted in the core application must be augmented so that it explicitly takes this additional layer into account; and this business logic must typically be duplicated, often in a different way, in the additional layer. This doesn't sound like a good thing.
What customers want is a single application, with defined identities, playing well-understood roles to collaborate around a given business process. Additional layers only mean additional work. That is, customers want to treat their partners as if they are first class citizens in the business process.
- What does SaaS mean (to me)
-
I've been thinking about this software-as-a-service thing for many, many years now (prior to joining MSFT I wrote one of the first internet chat applications with my buddy Scott, and later on I worked on the leading internet-delivered skills assessment system). Clearly there are different camps and that's a good thing. It means we understand that there are different classes of needs and desires.
The recent push toward social networking (hmm…) has its roots in the individual or casual group. That is, social applications are about connecting people and groups based less on their work affiliations and more on those intangibles: likes, wants, and desire to belong. This aspect of the new internet has bled nicely into other application spaces, like the one that I work in.
My work for the last few years has been around creating great experiences in line of business applications. These applications are usually known more by their acronyms: CRM, ERP, ERM, HRM, etc. It's also interesting to note that these applications traditionally are not productivity applications such as Office, but are more about helping to automate certain business operations.
It's this concept of user though that made me start thinking hard about how social networking applications are changing the face of LOB applications. For the last year my team has been doing research into SaaS LOB applications to understand why customers would consider purchasing them instead of traditional on-premise software. There are a few easily guessable and recognizable patterns in the purchase decision such as security, cost-cutting, and availability. These were aspects that we assumed customers were looking for and we weren't overly surprised to find them.
What was surprising, at least to a number of people on the team (I'm not saying I knew this, but I suspected it) was that customers were beginning to purchase SaaS because they expected to collaborate seamlessly with their trusted partners. This was the basis for the work that my previous team was doing last summer and fall. What's interesting about it is that it goes against the core design of (nearly) every LOB application ever built.
I think of SaaS in terms of some additional intangibles: collaboration, community, connectedness, completeness, and changeability (the 5 Cs for now). For me it's not about multi-tenant architectures, or feature sets, or any of the other things that we as architects typically worry about. It's about how to create great experiences for businesses. I'll talk more about the 5 Cs over the next week or so and try to explain how this new web is having an impact on the status quo.
- What is an application platform?
-
I'm working on a short paper / presentation that describes my position on what an application platform is, the services it provides, and what it does for the application developer. This is this initial outline. This doesn't talk about a specific (LOB) application platform, but instead talks about a set of requirements that a platform should meet. One of the things that started me down this path was noticing partners using the Microsoft CRM application as a platform. I'm curious to understand how other people think about this "problem" and whether there's any benefit in pursuing the definition.
I want to set the stage by talking about what I mean by "application" first. This paper will look at large-scale line of business applications. This isn't to say that productivity applications such as Office aren't applications, it's just that they're not the class of application that necessarily has this set of requirements.
Diversion
- Line of business applications
- Tools for automating the business process
- Productivity applications
- Tools for executing business tasks
Caveat
- A platform isn’t useful without an application
- It’s not possible to determine requirements without an application
- Most people aren’t interested in buying a platform – they want an application
- An application is the start, customers and partners want a solution
Then I'll talk about the necessary and sufficient requirements for a platform. I'm trying to keep this list as short as possible because most application logic tends to leak "down" into a platform thereby making the platform less applicable to other applications.
Platform services
- Identity and roles
- Rich type library
- Security
- Storage and persistence
- Extensibility
- Process identification and execution
- Solution packaging and containment
- Deployment models
Identity and roles
- What is a “user” of the system?
- Collaboration scenarios drive SaaS
- Roles come in many flavors
- Work roles (position), security roles, reporting structures
- Roles are facets of an identity
- Relationships between roles are primary
Rich type library
- Meta-types
- Constituents
- party, role, relationship, contactMethod
- Collaborations
- collaboration, interaction, goal, participation, structuredDocument
- Unstructured collateral
- simpleDocument, annotation
- Opaque data
- Reference data, lookup tables, auditing, etc.
- Data types
- enumerations, elemental types, higher-level types
Security
- Authorization and authentication
- Security roles are privilege collections
- Privileges provide access
- User interface, data, process, tasks
- Security roles trump work roles
Storage and persistence
- Storage structure is schema independent
- From an application perspective
- Storage is disconnected from logic
- From an application perspective
- The platform controls persistence
- Types DO NOT know how to persist themselves
Extensibility
- Schema
- Presentation
- Navigation
- Data capture
- Clients and user interface
- Process
- Business rules (simple and compound validation)
- Business logic (“big” and “little” process definition)
- Process execution structures (message definitions)
Process identification and execution
- Message definition and execution
- Actor identification by identity and role
- Task and work lists
- Loosely bound to an extreme
- Declarative vs. imperative
- Long-running business processes
- Transactional business logic
- One entry point to execute processes
Solution packaging and containment
- Everything is an extension
- Schema, process, presentation
- All extensions are named and grouped
- Names are like CLR strong names
- Packages are like applications or modules
Deployment models
- Multi-tenancy is important
- Multi-language per tenant
- Presentation is independent of the platform
- But the platform can provide presentation tools
- My WPC schedule
-
Wow, the calendar system on the WPC site isn't quite what I had expected. So, I'm going to keep my calendar in this posting. I'll update this as I pick times. Drop me a note if you want to meet and pick an open slot that works for you. The times listed here are already booked. Sorry.
(updated 7/6/07 10:30am PDT)
I arrive late on Monday. Well, later anyway. I get in around 9pm or so. I suppose I could be convinced to meet for drinks after I get checked in.
Tuesday July 10th
9:00 to 9:30 with Anne S at Breakfast at Convention Center
2:30 to 3:00 with Ryan T at Convention Center
3:00 to 3:30 with Peter H at Table 140
4:00 to 5:00 with Mike R at Convention Center
Wednesday July 11th
11:30 to 1:00 with RT at Hyatt
12:00 to 1:00 with John O for Lunch at Convention Center
1:30 to 2:00 with RT at Convention Center
3:00 to 3:30 with Mike S and Jim S at Convention Center
3:30 with Rob H and RT at Convention Center
Thursday July 12th
10:00 to 10:30 with David K, Jason H, and Mike B at Convention Center
3:00 to 3:30 with RT at Convention Center
I'm leaving for the airport at 3:00 on Thursday
- WPC here I come
-
I've finally registered for this year's WPC and I'm extending an invitation to MBS customers and partners to come chat with my team about some of our plans. We're currently putting together a short presentation to talk about what we're doing and how we think it impacts the MBS community. In return we're asking you to complete a short survey -- the plan is that is fits on a single piece of paper. If you're interested in participating, or just want to catch up, drop me a note and we'll set something up.
- Oh yeah, and the core of LOB applications *is* financials
-
So it took me seven years to come to this realization. Financials is a hard requirement for just about any line of business application. Without at least core financials it's impossible to really hit day-to-day scenarios that make business run better. Apologies to Jeff and the rest of the Green team. You were right.
- Why MS-CRM isn't a CRM product
-
For the longest time I've held the belief that the underlying infrastructure behind MS-CRM was there to support arbitrary business applications. It's funny, for the last six months I've been betting my career on that belief, and even more today, I truly believe that the core value proposition is that CRM is so extensible that its CRM-ness becomes secondary to how and why people buy it.
I've been talking to a number of customers and partners who have purchased CRM not for the CRM aspects at all (although I suspect they end up using quite of bit of the functionality) but for the platform components. It seems to have come full circle - the CRM product was, a very long time ago (in industry terms) designed to be the platform on which bCentral applications were based. After a short segue into on-premise core CRM functionality where the extension capabilities were disabled or hidden, the product is really progressing into a true platform.
It'll be interesting to see what happens over the next two releases. One that's been talked about is called Titan and that's the one that I think of as the core platform. I'm looking forward to seeing what that team can provide to the rest of Microsoft, and possibly to the industry, in terms of platform. Watch out SharePoint, there's a new kid in town and that kid knows all about business application requirements.
- What do I mean by hostable LOB application?
-
At the risk of upsetting a few people, I'm going to take a shot at defining what I think a hostable line-of-business application platform might look like. Those of you familiar with the CRM platform will recognize quite a few of the concepts.
First, by hostable I mean an application and platform running as a web-based client, rendered using HTML / CSS and supporting any number of modern web browsers. Note that I didn't say an application running inside of an ActiveX control or over something like Terminal Server. Yes, these are "hosted" applications, but only in a very limited sense of the word.
Line-of-business should be pretty clear. This isn't an email application, it's not an online auction site, nor is it a search engine (all of which are perfectly viable consumer-oriented applications). I'm also not talking about hosted productivity applications like word processors, spreadsheets, or presentation tools. I'm talking about those "big" applications that businesses bet their company on which automate "big" processes such as sales, financials, support, marketing, and commerce.
Clearly there are a few different classes of users of these systems. In particular there are members of the business licensing the software, there are customers of the business, and there are those folks on the periphery such as partners, vendors, and suppliers. I'm assuming that all of these "users" need some level of access to the underlying business process and data encompassed by the software. I'm also assuming that there are very different limitations on how the different users interact with the software (let's call this a role that the user plays with respect to the software). That is, the software experience is tailored to the individual using the software at a given time to perform a given task.
Let's look at an example of where software morphs itself - a sales order "process". First, a customer comes to the business' web site and browses their online catalog. They add a silver toaster to a shopping cart, specify some shipping and billing details, and place their order. Inside the software a sales order document is probably created, but the customer doesn't know this and certainly doesn't care how it's done as long as their toaster arrives in time for breakfast. Now, the system, if constructed to actually help the business, is busy fulfilling this order. To do this it breaks the order into a series of work items (let's assume for just one minute that this business builds toasters just in time) and distributes those work items to actors who can perform the work. Each of the actors (I don't really want to call them users or people because we might have a robot on the manufacturing floor that makes the darkness dial and that robot technically isn't a "person") interacts with the sales order indirectly through a role-specific view, but they're probably still using the same software system.
Anyway, I digress, as usual. You get the point that I'm talking about big software the helps the business do what the business does. Back to the discussion at hand. Each business is different and prides itself on being different. That means that they need software which is also different and tailored to how they best do their business. That is, the software is customized to their needs. I'm also assuming that the company hosting the software for the business (let's call them the provider) wants to make money at this providing business in which case they want to run as many of their customers as possible on as few pieces of hardware and software as possible. The provider wants to capitalize on the economies of scale that are possible with natively multi-tenant software. Ideally, if a provider could purchase a single machine with a single "license" and run all of their customers from it, while simultaneously supporting the customers' varied customization needs, then they would do that. That's what I mean by multi-tenant.
I'm not going to go into all the gory details about how to build such a system, but I will state the requirements here. First, the user experience must be tailored to the user's specific role with respect to the company. Next, the user experience must be standards-based (i.e. it must run in a browser and not use any of the weird extensions that many browsers have). Third, the overall business experience must include a level of customization that lets the business completely tailor the software to meet the business' specific needs. Next, the entire interaction model from purchase to provision to customization to use must also be browser-based (can't have any weird requirements to download some fancy development environment to make this work). Finally, the whole thing needs to be cost-effective from the provider's viewpoint (otherwise they can't offer it to their customers in a cost-effective fashion).
Quick update: one more way to think about the hostable line-of-business platform is that someone can come along and build a completely different application on it. It's a platform and it's application-agnostic.
Watch for part two…
- Poking my head out of the sand
-
Wow, it's been a long time. I kept trying to come back and write something, but between working on new projects and trying to figure out what I could actually write about, well…
So, anyway, just to catch up. I left the CRM team at the beginning of the year to work in an incubation / greenhouse team within MBS. We were initially focused (well, "focused" might be too strong of a word) on hybrid application models. That is, we were looking at ways to create applications that spanned the firewall either directly or indirectly. One of our motivating factors was to introduce a collaboration element to MBS assets. We tossed around a handful of interesting scenarios, and in true Microsoft style, we went way overboard in developing the initial scenario (a building contractor doing collaborative bidding and design on home remodel projects).
One of the good things that came out of all that scenario work was a prototype for a "data projector" that could take internal line of business data and project it onto a shared, hosted workspace. I can't go into a ton of detail around this yet because the concept itself was useful enough that we're going to pursue it as a product. That means I need to be hush-hush about it until the official product team makes an announcement.
In the meantime I'm looking at the CRM platform through the eyes of an ISV (again) to see what we might be able to do with it in terms of building non-CRM products. Watch this space for more information as we learn things (like the callout implementation from CRM for notes and documents is just plain broken).
PS - Caitlyn is doing great, she sleeps through the night and has since we brought her home. Talk about a blast watching her learn about all the cool things in her new world.
- Been very quiet around here
-
It's been really quiet around here, well if we define "here" as this blog. It has been decidedly not quiet at home. As many of you know I finally graduated from Seattle University in the middle of June. I also packed up all the crap that was in my temporary apartment and moved it back into the house (which, by the way, still is not done 7 eight weeks after the scheduled completion date). That was on Friday the 23rd.
Turns out moving on a really hot day under a lot of stress can put a pregnant woman into labor. Go figure. So, on Sunday 6/25 my first child, a girl named Caitlyn, was born. I've had about 30 minutes to myself since then between dealing with the new baby, finishing the house, completing an incubation project, and teaching my other children (a cat and a dog) that the new baby isn't a threat, but an opportunity.
Thus, it's been very quiet around here. I'll be around the office until the first week of August or so and I'll try to take some time to respond to questions and write a little about what I'm working on. Anyway, it's off to the grocery store to pick up something that'll end up cold for dinner. Now I understand that line from A Christmas Story about the mother not having a hot meal in 10 years.
- Multiple forms per "entity"?
-
Why not? I was just thinking about yesterday's post and had one of those disturbing thoughts that I get when I want to make software do something that its authors didn't intend (well, maybe, sorta, kinda).
Let's say I want to create multiple forms per "entity" (note the quotes). One way I might do this is to define a set of "like" entities in the metadata all pointing at the same physical location. I'd have to jury-rig the relationships a bit so the platform knew how to traverse them during create and update requests, but that's not really necessary.
If I were going to do this, what would I do? I'd define several entities that all mapped to a single, all-encompassing (data-wise) entity, I'd hide the super entity using roles and privileges because we don't want anybody messing with all that data (for some reason Steve Martin saying "you could melt all this stuff" pops into my head right about now… I don't know why), and then I'd configure-up all the forms for the shadow entities. Finally, I'd rename all the shadow entities so they show up, more or less, in the application. Then, and here's where the per-role stuff comes in, define roles for each entity.
In theory you should have different role-based views over the same set of data. Just a thought.
Update 13:45PDT - If I were really going to do this I'd just copy all of metadata for the source entity to the destination entities. There's no reason to go through the pain of actually creating the physical tables. That's why CRM is metadata-driven - so you can define things declaratively and the system will do the rest.
