5 Pillars of Connected Systems

TechEd was for John  and I the “5 pillars of Connected Systems coming out” party, as we both talked about them in our respective sessions.


The premise is quite simple:
Although absolutely fundamental; the next generation applications that enterprises want to build (what enterprises often refer as SOAs) require architectural principles and platform enablements that go beyond services and service orientation.


Services (often web services) enable connectedness; i.e. services permit to connect systems that were not (easily) connectable before; allowing the creation of scenarios not possible before; hence extracting additional values out of your systems — this is a very good thing! How this is achieved: best practices, anti-patterns, business alignment and similar topics around services are often discussed; but what is often not discussed is the new set of issues that are introduced by connecting these systems together. It is not common to see in SOA discussions the impact that SOA has on data manipulation and data architecture; likewise it is not common the read in SOA related article, how trust, access and authorization should be handled in these now cooperating systems. Furthermore, most of the discussions focus on what John calls the service delivery, and little on the service consumption (“client-side” of things, even though as we will be discussing, I am not a big fan of the word “client-side” anymore).


In the next following days I plan to write a series of short articles, discussing the 5 pillars of Connected Systems (namely Messaging, Identity and Access, Interaction, Data and Workflow) and why approching software projects along these 5 pillars is a very elegant way of separating concerns; also the current state and trends on each of these pillars will be examined.


Stay tuned, it will be a lot of fun  

Comments (3)

  1. dfo says:

    I think that if and when there’s a disconnect between the architect and the developer (the developer typically griping about some framework description being too abstract), it’s usually due to lack of understanding on the part of the developer. Just like in the role-playing games of yore, I don’t think one can become a mage (architect) until one has clearly explored the "lower arts."

    Anyway, that’s a side note. I’d be interested in you addressing the horizontal framework after you detail the 5 pillars. I’m finding in my work that if performance (caching, decoupling, granularity) is not addressed from the get-go, it’s a nightmare to try and remedy the situation further down the line since your foundation is unstable.