deltalounge

Since this blog is also dedicated to sharing resources that are valueable to me I decided to share my reading list of 2011 with you.

Lean Integration: An Integration Factory Approach to Business Agility

A great best practices book on integration. The first part provides description of the business value of Lean. It introduces the core concepts. As a manager that doesn’t need all the details you could just read this part and you can get a good grasp of the ideas presented.

The second part translates the lean principles from the world of manufacturing to the world of systems integration. It has great case studies that shows the principles applied in a real world context.

Part three of the book provides a “how to” guide. This can be used as a reference and as such is a great desk-top reference manual. This book is great and a must read for all technology and business practitioners and innovators.

Web Service Contract Design and Versioning for SOA

Great reference (not a book that I read front to back) on Web Service Design from Thomas Erl and his co-authors. This book focuses exclusively on the contract part of the service. Due to the depth it is a extensive resource to use besides others. The book is filled with extensive examples on how to meet the goals of SOA properly using contract design.

Via the site of the publisher and on iTunes are additional service design podcasts by the authors of the book. Could be a great resource to start with.

The Back of the Napkin (Expanded Edition): Solving Problems and Selling Ideas with Pictures

This is a great book on problem solving, extremely useful and in a sense thought provoking. It structures problem-solving into a six by five visual codex. This makes sense; you can literally see the evolution of the thought processes and the development of the insights take shape through the pages. Fun read as well.

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
• Architecture
• Release process

Small teams

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.

Architecture – Keep it simple

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.

Release process

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.

SOA and Cloud Computing

Cloud Computing and Semantic Web technology

…

In October 2011 Gartner published it’s Magic Quadrant for SOA Governance Technologies. Gartners sees the market for SOA governance technologies keeps changing, driven by more comprehensive requirements from end users. The most important change since their previous report in 2009:

Clients today prefer to buy SOA governance solutions that will serve their purpose throughout the whole SOA endeavor, governing services and artifacts through different projects from planning and design all the way to implementation operation and retirement.

The most important change that I see at our customers compared with two year ago is that they more more interested and willing to invest in governance technologies.

What is SOA Governance about

SOA governance technology is about:

• Tracking and monitoring the artifacts in a SOA
• Enforcing and ensuring compliance with the policies associated with the artifacts
• Measuring the outcomes related to their use

Oracle’s SOA governance offering

Oracle’s offering in the Governance technologies market is part of it’s Fusion Middleware product line. It includes the following products (see this this blog):

• Oracle Enterprise Gateway and Oracle Web Services Manager – Full life cycle policy management
• Oracle Enterprise Repository
• Oracle Service Registry
• Oracle SOA Management Pack

This number of products and the complexity of Oracle’s offering can make it hard to get a good grasp of what product will cater your specific needs. Should you need more insight visit our SOA governance seminar.

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:

• What is SOA Governance and Why do we need it?
• SOA reference architecture – The importance of solid standardization.
• Service life-cycle governance – Design and build the right services and the proper way to reuse them.
• Service repository – With examples of repositories based on Oracle Enterprise Repository (OER) and a wiki.

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.

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.

What to do?

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?

Recently while listening to OTN ArchBeat podcasts, a panel discussion on Reference Architectures (part 2 and part 3) I was thinking back to some pieces I wrote on industry data models and processes that I didn’t share with you yet. There a some similar argument to using these and reference architectures.

The value of reference models whether it contains data models, standardized messages, processes of a reference architecture, is or should be in a faster time to market and better quality of the solution.

Handle with care

What makes it hard to achieve this value, is the fact that these models contain always far more than is needed. That can be considered a waste. Even the parts that are not used still require attention while implementing and maintaining. This incurs work to understand the complex model, hide the details you don’t need, and customize and extend the parts you need.

Implementing a reference model requires spending time to determine how and to what extend this model meets the needs of your business? That is typically something you have to discover for yourself. It is where the majority of the time is spend! If you don’t go through the effort of understanding your business requirements, you are missing understanding of how the business can and should use the model. That makes it very hard to determine the value of the end solution to the business.

When using a reference models you should be aware that your business is not average. In some shape or form it delivers value to your customers in away a reference model doesn’t provide. Reference models should be used with care your business deserves.

Today I presented at ODTUG Kaleidoscope. The presentation is aimed at supporting architects and especially developers to choose the right integration infrastructure for a job.

You might have read here or on other blogs that SOA isn’t a purpose. It is a means to an end. The same goes for all the technologies that we use when implementing a SOA, or an architecture, or an application in general. So I wanted to share the next video with you since I think that it – in an even broader perspective – shows this point. Technology itself is not good or bad. It all boils down to how we as people use it.



Source: RSA.org 21th century alignment.