What is the most feasible implementation of this architecture ?

On the Enterprise (aka Generic) level, more or less all of us Architects, are capable to agree on the universal diagram, providing Enterprise Architects view of an modern company. Of course, any modern company is relying 99% on the success of its IT assets.

Universal Enterprise
Universal Enterprise IT Landscape

Here we have it. Nice clean, generic, and universally applicable. Just as any good IT Architecture should be: Generic.

The TOGAF(R) III-RM diagram is nicely mapping to/from the standard Enterprise Architecture Methodology.

I actually like that diagram. I find it particularly useful when Application Landscape migration is planned. It helps me explain to key stakeholders the root logic of application types. And the key qualities to be attached after the catalog is finished. Before the legacy IT landscape starts to be migrated to the first seemingly simple but crucial, still generic but full IT landscape top-level diagram. Call it “Company IT Constitution in one diagram”, if you like.

Otherwise, as soon as we start being Specific, and start “prescribing” particular “silver bullet” technologies we are heading in the direction of endless debates and accidental marketing. And any architect loves nothing more but to bash the marketing people into submission. Which in turn leaves the “innocent bystanders” aka customers, without a viable solution, at the end.

That is all true until key stakeholder asks the following question:

“What is the most feasible implementation of this architecture ?”1

Then (as ever) you have to put your magical Solution Architect hat on. You have to muster all of your practical experience and you have to act. And this is what I am going to do. I will jump off my very high EA horse and answer this question. I will boldly name the tools and technologies my experience is telling me are the most feasible ones to implement this architecture. At this day and age (circa 2013).

They can be, but very often snazzy diagrams do not lead to feasible anything. The diagram below is deliberately left as a “back of the envelope” Architecture and/or Strategy.  That was deliberate. This is an order of magnitude close to the solution. And, it also shows how simple and immediately applicable this architecture is.

Let’s start with the popular “Front Cluster” which are hosting “Business Services” used to compose modern (Web) Applications. This is where I recommend SharePoint. SharePoint market share is still growing exponentially. At the same time, SharePoint (SP) as a product is in widespread (global) use for the last 10+ years in almost every typical enterprise, where (again) most of the IT landscape is based on the Microsoft stack. And my (hopefully) pragmatic view is that this makes 90%+ of all medium, large and largest companies on this planet.  A lot of you will now do their best to prove me wrong. But, still, I will stick to this point of view.

Now, the reality. 5+ years is considerable time in the IT context, and all these SP adopters, are starting to understand what actually is this expensive thing called SharePoint. I mean they are cautiously going beyond simple intranet usage patterns. They are starting to understand (and adopt) the primary intent of SP’s existence. And that is SharePoint at the front of the IT landscape in the typical company of the near future. Next 5 years at least. A company whose workforce is 90% mobile and is using anything as their personal computing device. And yes, this is actually the “Cloud + Client” paradigm.

DBJ Solution Architecture ©to Date, by DBJ.ORG

So, you are the CIO or chief EA or something clever like that. You asked me a question, and this is how I think our architectural vision should be shaped up. SharePoint in the front, BizTalk in the middle, and everybody’s nightmare: Legacy Monsters in the back.

We both know you have no serious mission-critical system yet, which is completely in the Cloud. And we both know that the Company you are in right now is far from ideal and cleanly divided IT landscape. As nicely depicted on the first generic diagram.

Here the key layer is in the integration and data transformation. From the legacy data and legacy systems in the back to the front layer components making the applications. And this is where BizTalk has no real competition. Calling BizTalk a “business process automation platform” is a serious mistake. BizTalk is first and foremost an Integration Platform. It nicely integrates and decouples in the same time your future from your past. Web App’s from Legacy IT.

Right now, I do not know of a more feasible plan for any standard enterprise bogged down knee-deep in the IT legacy mud, to move forward, solving (almost) all the issues of every medium to large IT landscape.

Put all of your legacy nightmares in the back, use BizTalk to integrate, and have the complete front side implemented as SharePoint sites and web applications. As a side effect, and if you do it right, instantly all is also very compliant and very manageable.

I dare to claim this is one very feasible proposal. Also future proof, and also based not on pre-sales marketing architecture, but on your reality and on the two most mature software platforms: SharePoint and BizTalk. Everything else is vested interests and legacy kingdoms built around decades of legacy systems in existence. I would stick my neck out and claim: for you right now dear CxO, simply there is no other feasible choice but to implement this strategy.

And Cloud? Where is the Cloud in this I hear you asking a bit nervously?  My opinion: Not today (circa 2021) but at some future point companies will be able to plan and execute in some simple Cloud+Client paradigm. The key to that future is a secure and manageable integration with legacy parts on the ground. Cloud can be anywhere you like over the above diagram: external to it, or covering each of the 3 parts (from above) or covering them all. This strategy/architecture still stands as it is. It can be implemented in or out of the cloud or in a combined fashion in an orderly migration to the full Cloud computing paradigm.  This is how you get to the Cloud. In small upward, careful steps.

The happy cloudy time will come as soon as all of that landscape from above can be lifted to the Cloud. But this is not going to happen any time soon. And I think every CxO knows it quite well.

1This is the question, I would recommend anyone to ask her architect. ASAP.