Due to the amount of snow (an example on the right – this is the size of ice slabs I got from under the car) in the recent days I became another one of the remote workers; during which I started to think, whether the current setup of mine is actually suitable for longevitied remote working – and I can declare, it's far from being perfect, but can be made so reasonable quickly. Right now I'm using a Surface RT as my main device as part of a device evaluation, and its possibilities to get it connected to external keyboard, mouse, and display do fit my needs. So what are the missing points? One easy to miss is your seat – to let you ergonomically sit. Another one would be good internet connection – luckily I did not have any issues ever with my provider. Lastly, the comfortable noise level is something I need to invest into. Right now I'm using an old LifeChat device, which suits me most of the cases – save for when I'm doing phone calls. I'm now positively looking into investing into a physical IP phone with headset (hopefully either noise cancelling, wireless or both). What else you try to make your remote work life better? And yes, I'm familiar with the posts of probably one of the biggest remote work enthusiast.

Yesterday I submitted nearly a dozen projects for summer internship, covering a wide range of topics from UI mashups to infrastructure developments; and was thinking about what language should I use when describing the projects? A while ago I was chatting with a friend of mine working as a customer care specialist at a company that is basically focusing on outsourcing – he complained he does not understand my blog. Which made me wonder: what courses I'd suggest to take for someone who wants to be able to work in such environment – in 2014. Next to some basics like 'requirements analysis', 'solution architectures' what else would be on the ideal list (eg for someone you would be happy to outsource all of a sudden)?

While reading another wonderful piece from Scott Hanselman, it just came to me in a sudden – I it possible, that we still haven't arrived to the age of enterprise templates? What are (or better, were) enterprise templates?

As time evolves, patterns and frameworks also do evolve significantly. Some APIs, features tend to become less useful, less 'modern'. If you happen to work at an enterprise, these might be even put to an official list to avoid, even companies implement tools that either at checkin time or later on, automatically; or manually, using crucible or similar tool do hunt down these anti-APIs. Isn't there an easier way? More than a decade ago I've chosen the following as the title of my thesis: Enterprise Templates and Domain Specific Languages – Enabling Modification of Visual Studio.NET IDEs to Comply with Company Standards and to Enhance Developer Productivity (yes, title brevity wasn't an aim). So, what this was about? Visual Studio (and also Eclipse, IntelliJ, etc) easily allows creation of addons/plugins. One type of these addins is the ability to create a DSL – Domain Specific Language. In my thesis I showed a way with actual implementation on using DSL to recreate the normal development environment, language, base class libraries, etc. – minus those particular features you want to get rid of. You want to introduce a warning if someone uses UrlPathEncode? You want to get rid of the property EnableViewStateMac and default it to be true? All of these is easily possible with enterprise templates.

Why it did not got into the common knowledge? That's a rather good question. Have YOU ever heard of enterprise templates and the possibilities described above?

Another movie I found is from the renowed UX expert, Chad Hower, who is speaking about Kudzu and WooHoo:

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.