Part II of Eugenio Pace's "Anatomy of S+S – Considerations for Building, Running & Consuming S+S Applications", where he continous to speak about building multi-tenant architectures.

In the next few days, I'm going to repost some of the old videos I found why cleaning; let's start with Eugenio Pace's "Anatomy of S+S – Considerations for Building, Running & Consuming S+S Applications", where he speaks about building multi-tenant architectures.

A Purchase Order is a complex object which represents data stored in multiple, sometimes diverse, loosely coupled tables (sometimes these are even not rectangular today). Such complex graph of objects must be persisted in and out of the data base as a unit (not only speaking transactions, but also composition and association). Developers are tend to be more productive when working with the complete object, using a full or a subset of operations, depending on the abstraction level of the underlying framework. Complex object graphs like sales or purchase orders (having 100+ logical and physical tables) are very common in business applications (looking at sap again, probably). The operations running on them support a compensation model – as today's rich user interfaces often interact with multiple services in a given, predefined conversational fashion. As we all expect, these services may not all be read only –and even could be much more complex than crud. For example, each line item in a complex object graph actually calls a service to allocate inventory. As modification to these complex graphs needs to be still acid, these allocations must be rolled back if the user cancels (see reversible operations), or confirmed and persisted if saved. For this to naturally work, the operations should have built-in support for compensation, e.g service oriented transactions. The fact that these operations are reversible and cancellable (e.g restartable) provide guaranteed "forward only" execution (and server side scalability), the integrity is ensured by restarting execution until completed. Moreover, many batch oriented tasks are simply far too large to write compensation logic at once, yet need multiple service, logical (and usually in the end, database) transactions. Of course, in our multi-tenant world, the actions executed support multiple services in a flexible, pluggable model (see dependency injection and service discovery, but no uddi) – some application logic is regularly changed for every customer of the upcoming application (e.g. taxation, commissions); or multiple algorithms are known ahead of time but are applied based on context. And one of the hype topics – BI. BI is desired when the user is working (information at the fingertip), not just when they are actually analyzing information. IMHO, to be usable for the business, BI model has to derive from the original data model, and not the application entity model – this is a mistake easy to make.

How does the architecture for such a platform should like? As we are facing it from the business side, let's stay with model driven architecture (people opting for another architecture please leave their comments below). We have the entity, as heart of our abstraction. The entities compose via compositions and associations, forming complex graphs. Entities do have identity (key), their factories, the set of properties, and a set of services (to allow validation of incoming data modification messages). This is where our persistent data abstraction finishes, and our business logic abstraction starts. Former is to handle defaulting, validation and calculated values; latter for handling complex transaction and customization scenarios. What does the latter contain? Cancellable and reversible operations (with possibility for operations to compose other operations for complex business logic chains), that operate on entities. These too have services, that support long running transactions, has parameters, factory, and selectors that for operations capable of supporting multiple services select the relevant at runtime.

These are the first level concepts of a model in my ideal model driven architecture. Moreover, we can define concepts like a change set – set of entities and operations that are running on top of them that can be committed and aborted together; so we are forming transaction abstraction as well. For the entity we can drop in some cubism as well – have measures and dimensions.

So we have our framework, somewhere at the bottom. We do have a set of 'ISV's (let's call them "Tier 1" ISVs), who develop business applications, and do sell them through a cahnnel. However, there are always IT development teams of big enterprises who would buy directly and build application (usually solely) for internal use. So what would a Tier 1 ISV do? Of course, one of the channels is to sell the applications to the enterprises (little more pre-boxed approach than the previous one), however this is not the only way. We can define Tier 2 ISVs (and Tier n as it goes into a loop), who integrate extend or OEM another ISV's solution. These Tier 1, 2, N ISVs do sell the results to enterprises and to middle market firms as well. These middle market customers do buy from a number of channels (and again may extend the solution). Are we ready? Clearly not, we forgotten all the VARs from the equation: they do implement solutions and do simple application development. Usually they don't sell the results to enterprises anymore, but both the middle market and the small businesses can benefit from the results. So, these small businesses buy exclusively through the VARs or they buy the retail version from some Tier few ISV as they cannot afford the overcustomized version, but are OK with the multi-tenant VAR added versions. This is how I do see the value chain for business app creation when I do own the underlying platform. Which level you think you are?

So, what are the basics of such a framework that provides you the ultimate business power? Such a platform provides abstractions. Programming and business abstractions – about these later, a few lines below. Next to it, it implies a prescriptive architecture (ok, with some flexibility, but in general terms, it implies). It should (or probably, would) be suitable for the development and in today’s continuously deployed world also for deployment of the business applications – on demand, on premise, on mobile. Characteristics of such an application? Distributed, service oriented, cloud powered. Tend to be from simple one screen apps to huge, 1000+ forms, 500+ tables, millions of business logic LOC beasts (should you think of SAP here?). Part of the abstraction, they do have some repeated patterns, that the framework should fulfill, like – UI: setup, data entry, reporting, querying, process initiation; logic micro patterns: data types with composite ones like currency and quantity; logic low level patterns: defaulting, validation, calculated values, sequences; high level patterns: symmetry (a sales order is someone else’s purchase order), workflow. Of course support for edit all of these at runtime, have multi-tenant (SaaS) capability. These characteristics altogether are the ones that drive the abstractions we make. Now compare this to what you get when you try to stop at having an ORM with bound UI controls. And we haven’t touched BI yet. Next time I’ll try to drive into the value chain; oh boy, that can get pretty nasty and complex rather quickly.

I mentioned I want to start a series on what does a business app actually is, how does Siena change the playground (if it does change it). I’ll start with the historic world, so what elements did a framework designed to create business app contain back, a long time ago? Of course, it needs to have an ORM (what would a business app do without an ORM?), a multitude of UIs (yes, desktop AND web), and… and this is the point when some of the frameworks I previously used stop. They keen to provide some prepackaged controls – look, how cool this grid is -, and then that’s it. So, what I think we are missing here? Validation, as one of the items. Validation throughfully the system, from db to ui, which can break and roll back… hey, I just found another missing point. Operations, that defined on… business entities! And these entities execute these through following collaborations between the items, using runtime metadata service to find out runtime information – information like data location (sharding, multiple sources). Finding out security – role based, row based with custom entitlement filters, column based. You need to cache and invalidate, provide pluggable configuration, serialization, but hey, by having serialization I can do workflows with hydrated states! Add a dash of BI (you always have to add BI), services integration, and you are… have created a compelling system that with appropriate level of documentation and support will eventually work.

So, where is the catch here? What is missing? Empowering the developer and the end user! Add entity designer, service designer, component editor, codegen, metadata explorer and editor, BI wizards, ide integration, colorful themes, clippy, – I got Light Switch! Make it work in metro design – hey, I got Microsoft Siena! So in the following posts I’ll discuss some of the elements from above in more details, but this is for just setting the general tone, and topics list.

I might be the last one people turn to when the question about Satya and whether it would make good for the company arises (is it obvious I write about Satya Nadella and Microsoft?); but still here is my personal opinion: During my career path inside Microsoft I did have the opportunity to work with some of the greatest (and I do have 'shaking elbows' picture with most of them). Who am I thinking of? Don Box (the soap and XML webservices guy), Anders Hejlsberg (the guy behind Pascal, Delphi and C#), Robert Scoble (if you haven't heard the name – he turned Microsoft to be open – channel9, blogging, ctp, etc all his idea and effort), Norm Judah (services guy), S. Somasegar (head of Developer Division), Scott Hanselman (everything and anything guy, and one of the best speakers I ever seen – whether it is about life, remote work, or… it just rocks), Scott Guthrie (the guy in the red shirt), etc. (side note: Hey, soon I can increase the picturesque hall of fame of mine with no one else but Bjarne Stroustrup himself – if you have missed it, he joined Morgan Stanley recently to work together with my group) So, why I lay out these names? I did have the opportunity to have photo shoot with Satya, but I didn't. The reason? Not feeling the omnipotence of Gates? The ever lasting burning visionary powers of Ray Ozzie? The inability to dance like a monkey? I don't really know. Just he did not radiate the same unspoken glory as the rest of the wise men. Because he was always the one who could raise on the back of giants. So, based on my experiences, the next era would be a balanced growth, with focus on some of the more conservative businesses – enterprise, developers, servers. His humbleism and down-to-earth manners will resonate well with stakeholders, but his beliefs on server and enterprise will resonate well with… stakeholders. So, the 12th place in the board will go to ValueAct, but I think by the time they actually being enacted there, most of the changes they were keen to happen will eventually start happening anyway. So… Does this mean Nadella is being supported by ValueAct? Might be the case, and we will never find it out.

(Quite) a long time ago I was part of a team that was working on a product that was to change the world (yeah, every project you take seriously is one of those world-changers). The aim was not smaller than to give power to the user, power to the developer by letting them considerably more easier create business apps. Right now I'm happy to state – in a way the dream has come true. Siena and Light Switch are incarnations of the work I done literally a decade ago. What was changed? And how? And what is the difference? The aim of this series I start now is to look into the path that lead to these tools.