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?
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.
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.
Just uploaded the presentation I gave at the Seminar “Lean & Agile IT: beter resultaat, betrokkenheid en IT volwassenheid” (Dutch) on Lean Integration. Besides the aspect of getting a lean process to create integrations we also focused on how integration is lean in the sense that it can create value.
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.
Later this month on the 27th and 28th of April the 4th International SOA Symposium and the 3th International Cloud Symposium will be for the first time held in Latin America – Brasilia, Brazil. More info on previous editions can be found on this blog. The 2011 SOA Symposium program consists of:
Given the location simultaneous translation (English-Portuguese-English) will be available in all technical sessions. For the complete agenda or resources from previous conference, check the site. Videos from the 2010 edition of the SOA Symposium can be found on InfoQ.
Although there can be a lot of debate on what is Architecture in the world of IT, what IT degree programs discuss about architects, and on who is an architect and who isn’t, I think it is clear that it is not exactly Brain Surgery. And i think that is actually a good thing. Although the implementation of a (Service Oriented) Architecture is in most cases bound to hit vital parts of an organization it isn’t …
And even though there can be just as many parameters in the larger equations, architecture isn’t exactly rocket science either…
