Posted by Gero Vermaas around lunchtime: August 31st, 2011
That was the question on my mind while walking out of an hour and a half meeting which was attended by 6 people. The problem wasn’t that complicated, we went into the meeting with 3 alternative solutions: so why did it take so long to pick one? It kept nagging me a bit and then I recalled the “Simple Architectures for Complex Enterprises” book by Roger Sessions. By applying his approach I was able to determine if we made the right choice and I’ll describe the results below.
Posted by Gero Vermaas in the early morning: August 19th, 2011
A while ago I realized that the C in COTS stands for Customize, so in reality it is Customize Off The Shelf (and not Commercial Off The Shelf). The premise of COTS products is that it reduces system development costs and long term operational maintenance costs. Sounds like music to management and procurement departments. Reality can be different. Realizing that the C stands for Customize highlights one of the pitfalls most people are aware of: the amount of customization needed to make a COTS product fit in an organization can be huge. But there are more pitfalls and in this blog I’ll highlight a few.
Posted by Gero Vermaas in the early afternoon: December 1st, 2010
At the start of your career your backpack with is filled with lots of theory and as your career progresses more and more experience get’s thrown in, perfect. At some point you won’t be learning new things if you keep doing the same role. That’s why people take up different roles and grow in a team. However, the goal of the team’s you’re in often remains similar: develop system X that realizes user stories Y and Z. Many people do lots of roles, but all on the ‘producing’ side of the IT. I personally experienced the value of jumping to (one of) the other side(s) for a period of time. After returning to my original role I became much more effective.
Posted by Gero Vermaas in the early afternoon: July 28th, 2010
This is the tenth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The tenth principle we discuss is called “Architecture emerging from Projects“. (more…)
Posted by Gero Vermaas in the early evening: June 21st, 2010
This is the seventh post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The seventh principle we discuss is called “Architecture Initiated by Business Goals“. (more…)
Posted by Gero Vermaas in the early morning: May 27th, 2010
This is the forth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The forth principle is call “All hands on deck early on” (initially coined by James O. Coplien). The essence of this principle is that all stakeholders of a project are involved at the start of the project.
Posted by Gero Vermaas in the early morning: April 28th, 2010
This is the second of a series of blog posts discussing Lean Architecture principles. Each post will discuss one principle and applying these principles will result in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The first principle that we discuss applies to the architect role and is called “Always Involved“. The architect role is not limited to one project phase or even one project, a good architect takes a much broader perspective. The Lean Architect constantly communicates with all stakeholders (from business till operations), plays an active role in running projects, and ensures that lessons learned in projects are known and where applicable used in other projects.
Posted by Gero Vermaas around lunchtime: June 29th, 2008
The Top 10 SOA Pitfalls countdown hit #1 last week with Rik de Groot’s post on “Ignoring culture when introducing SOA“, time for a wrap-up.
Putting all pitfalls together in one simple 10 item list quickly reveals a grouping of types pitfalls. Number #1 and #2 are both related to organizational aspect. If the culture, mindset and attitude are not right, these are typically the pitfalls that a SOA endeavor may run in to. The next group covers the items #3 till #7, these are all related to architectural/design skills. And the last group, numbers #8 till #10, relates to implementation issues (although proper design could help to prevent these pitfalls from manifesting themselves).
Posted by Gero Vermaas mid-morning: June 2nd, 2008
Last week Vincent explained the BDUF Pitfall en this week we’ll continue with #4: Incorrectly applied Canonical Data Model (CDM).
CDM is one of the silver bullets often fired in SOA projects. It should address miscommunication, ease integration and reduce integration costs. It surely can facilitate all of this, but attempts to use a CDM can also turn your SOA project into an endless discussion because one attempts to cover too much, because of a lack of alignment with business and because of a lack of design principles.
(more…)
Posted by Gero Vermaas at around evening time: May 12th, 2008
After discussing #8: Security, let’s move on to #7.
Incorrect granularity could mean that a service covers too much functionality or too little functionality. Incorrect granularity of services in your SOA can lead to bad performance, low reuse possibilities, leaky abstractions and services without added business value. . Common causes for this are bottom-up and/or top-down design and taking a too narrow perspective (project instead of company scope). In this blog we’ll first take a closer look at the previously mentioned symptoms and their causes. And then we’ll explain why the solution lies in taking a business perspective when designing services.
(more…)