Recently my latest Whitebook was published, called ‘Integratie maar dan lean‘. The article focusses on solid tips to move your integration practise to a more lean version.
It’s in Dutch. International readers can use Google Translate. An English translation can be provided on request. Please leave a comment with your email. Have your integration lean 
In June gartner published it’s Magic Quadrant for Application Infrastructure for Systematic SOA Infrastructure Projects. Due to the nature of SOA initiatives the selection of technologies and products aimed at supporting the implementation of the SOA infrastructure is done upfront. The resulting platform is shared among SOA applications and other integration initiatives in the enterprise.
To address the need for SOA infrastructure vendors typically have “SOA suites” of “SOA platforms”. These package products like:
.
All open source vendors are in the visionary quadrant. In some cases their offerings are more modern than the Leaders’ products, since they are hardly burdened with backward compatibility issues. However these vendors are constrained by their small size or sometimes inconsistent execution.
In general the open source platforms are less expensive and easier to implement and deploy. However their offerings are generally less comprehensive than the Leaders’ offerings. If these offerings fit your requirements this could be an easy-to-use/low-cost SOA infrastructure for your organisation. The open source platforms are a strong technology offering.
While preparing guidelines for the usage of the Oracle Service Bus (OSB) I was looking for a definition of a Service Bus. There wasn’t one on my blog yet (more posts on integration) so i decided to use the following and share them with you.
From 2009 Forrester has used this one:
An intermediary that provides core functions to makes a set of reusable services widely available, plus extended functions that simplify the use of the ESB in a real-world IT environment.
Thomas Erl offers the following description of a Service Bus::
An enterprise service bus represents an environment designed to foster sophisticated interconnectivity between services. It establishes an intermediate layer of processing that can help overcome common problems associated with reliability, scalability, and communications disparity.
An Enterprise Service Bus is seen by Erl et al as a pattern. That is why it is even more important to share what that patterns is. Later on I’ll also shortly describe the VETRO pattern. Also a very useful pattern to use when comparing integration tools or developing guide lines.
On the SOA patterns site we learn that an enterprise service bus represents an environment designed to foster sophisticated interconnectivity between services. The Enterprise Service Bus pattern is a composite pattern based on:
The VETRO pattern was introduced by David Chappell, writer of the 2004 book Enterprise Service Bus.
We also used this pattern to compare Oracle integration tools and infrastructure. It can be very well used while choosing the appropriate tools for a job and deciding on guidelines on how to use these tools.
According to research by the The Global Language Monitor:
SOA continues its reign as most confusing acronym
The Global Language Monitor is a company that collectively documents, analyzes and tracks trends in language usage worldwide, with a particular emphasis upon the English language. GLM is known for among others its list of High Tech buzzwords. Here is their top 5 of Tech Buzzwords of the Second Decade of the 21st century, thus far (2010, 2011 & 2012) everybody uses but don’t quite understand (with commentary):
The Most Confusing Tech Acronym of 2012: SOA (Solutions Oriented Architecture), continuing its Most Confusing Tech Acronym of the Decade reign.
Watch the Mashable video on this list:
Read the full version on The Global Language Monitor.
Despite all the effort by numerous people this also shows that it is hard to get a solid grasp of what SOA is. We showed that before by comparing some of the definitions on (web) services and processes. We might learn from this that it is even harder to have as we call it “the business” initiate SOA projects and programs. Even if together with the business we get a clear picture of the benefits of Service Oriented Architecture is, it remains a challenge to lead them through this stuff they don’t really understand. Feel free to share your experiences in the comments…
One of the most important tips in succesfully implementing an enterprise or application architecture has always been to communicate it really well. Since human relations are at the heart of communication these should be studied and refelected on from time to time. In this post I wanted to share an opportunity on that for you; a very small course on human relations.
The first time I read about this course was in Terry Starbuckers blog post on One Of The Best Leadership Lessons Ever…..In Just 29 Words. It doesn’t take long to find out that this short course in human relations has spread over the internet. However it’s contents aren’t new or unique doesn’t make it less valuable or profound.
The 7 most important words:
“I don’t know, but I’ll find out.”
The 6 most important words:
“I admit I made a mistake.”
The 5 most important words:
“You did a great job!”
The 4 most important words:
“What do you think?”
The 3 most important words:
“If you please …”
The 2 most important words:
“Thank you.”
The 1 most important word:
“We.”
The 1 least important word:
“I.”
I like it because it is simple, human and humble. Maybe you’d like to print the slide from Terry Starbucker.
Some employees are remarkable, possessing qualities that may not appear on performance appraisals but nonetheless make a major impact on performance. This won’t just shine through in their own performance, but also in that of their peers, department and organizations. Read about these 8 qualities in a post by Jeff Haden.
Just uploaded the presentation I gave at the Seminar “Architecture and Governance”:
Still wanted to share some thought and ideas with you I took from the LAC 2011 – the largest symposium in The Netherlands on architecture in the digital world. The larger part of this post is taken from the key note on Speed and Innovation through Architecture by Jan Bosch. He states:
Speed trumps any other improvement R&D can provide to the company.
Speed and time to market deliver far more value than increasing the efficiency of a process. This especially holds for non-repetitive process like (software) product creation. To increase the speed and reduce time to market we should focus on the following aspects:
Small teams work on the people side because a team member can experience the fruits of his or her individual efforts while on the other hand they contain the rewarding social element of camaraderie. Both are necessary for people to see their work as fulfilling.
On the process side, small teams increase speed because of the lowered need for coordination within the team and the existence of complexity. A team larger than three is required because of the need to learn from each other, the ability to deliver significant work and enable preservation of knowledge from the feedback the team has encountered. To get speed in the team at a high level the team needs to be self directed and managed.
First and foremost make sure your architecture enables you to simplify things! Keep in mind that rules and constraints can create complexity. And that is something you wanted to avoid when you started with architecture in the first place.
Architecture provides simplicity, compositionality and is designed in parallel with software development
An example would be to limit the number of things a team has to worry about during development. This could be done by applying the 3 API rule and there are other ways as well. Allways ask the questions whether the architecture enables the development team to perform.
In order to get speed into your development process you need to know/measure what people do, not what they think. Factor out opinion and chose data. To get proper results here you need a short PDCA cycle. Check and measure to get results back into your development process. This requires that you release early and often. Which in turn demands automated deployment and test.
Earlier this month a talk by Thomas Erl (bestseller author on SOA and Cloud Computing) on SOA, Cloud Computing and Semantic Web technologies became available on the Arcitura Youtube channel. This talk gives a less than 30 minutes overview in how these work together. It has a focus on highlight promissing areas of synergy.
The definition used for Cloud Computing is:
Cloud computing is a specialized form of distributed computing that introduces utilization models for remotely provisioning scalable and measured IT resources.
The definition used for Semantic Web Technologies is:
Semantic Web Technologies represents a technology platform used to describe artifacts, their properties, and their relationships using machine-processable language.
…
On December 13th Whitehorses will host a seminar on SOA and Governance. During this seminar we will show the value of a proper architecture and governance for your organization. In the presentation you will get clear guidelines and steps on a pragmatic approach for implementing a manageable SOA solution.
Some of the topics:
rsvp.
While in a previous post I was arguing that we should handle industry models with care, because of very inconvenient side effects. This week I’ll blog in a similar way on centralization. Among the effects of centralization are often overlooked or neglected dis-economies of scale.
One of the main reasons for centralization is to gain economies of scale. Less known are the dis-economies of scale. I’ll give some examples in the paragraphs below.
The cost of communication between the central group and the rest of the organization. Although there are lots of tools that make communication easier. Distance in the physical sense or within an organization can create boundaries. These have to be dealt with and there are costs incurred for that. Besides that it has to be clear who to communicate for what matters. This, in my experience, is not always the case. With a greater (organizational) distance more effort has to be put into this.
There is a large possibility that top heavy management in a centralized department becomes isolated from the effects of their decisions. In other words the feedback loop is broken. Because the communication loop is broken, decision become more and more dysfunctional. This due to the lack of real world knowledge that should be incorporated in these decisions.
Centralization can lead to reduced agility. On one hand standardization is a great asset. The larger part of architecture, whether it is enterprise architecture, process architecture or infrastructure architecture, is about standards and reducing the “solution space”. This has several advantages, among which the reduction of software- and systems entropy. The downside of a centralized body that maintains standards is that it probably will lead to inertia and unwillingness to change.
I’m a big fan of (open) standards. They simplify life! However we should not neglect that standardization comes at a cost. There are the costs for implementing, adapting to and maintaining standards in our organization. Say for example that we use a canonical (data) model. There is are maintenance costs (at least some effort) while adopting to change outside and within our organization. These costs of standardization tend to be hidden.
Bring the effects described before into the business case for centralization. You did make sure that there was some sort of trade off when you decided to centralize a certain part of your organization didn’t you?
Take measures to prevent these risks. It goes without saying that these measures will take effort, time and possibly money. Now you know you’re going to take measures don’t you?