Xebia Blog

Last week Viktor Grgic explained the Missing skills en this week we’ll continue with #2 - Unclear ownership / Project based funding

In the world of standalone applications, there is typically a clear sponsorship and ownership of an application. There is also a single project with one project manager. The systems could be small or big, but the pattern remains the same. Funding is based on a business case and can be easily defended.
In SOA world, the story is different. There are the usual projects, each having their own objectives and often reluctant to work on generic services or enterprise components. If the ownership and funding for these components and aspects are unclear then chances are high that nothing happens on enterprise level or that it's not according to enterprise architecture or nobody feels responsible when things on enterprise level go wrong (e.g. security).
Several projects working together is not a bad situation, but there should also be a SOA steering committee and SOA competence center well funded and supported by company board.
(more...)

Filed under: Project Management, SOA
2 Comments

Last week Gero Vermaas explained the Incorrectly Applied CDM en this week we’ll continue with #3 - Missing skills

Just like any other paradigm, a level of new knowledge and experience is required. Unfortunately, SOA requires lots of new knowledge and experience. It requires a different way of thinking of more or less everyone involved. People are used to closed environments on both organisational and technical level; largely well protected from influences and unwanted dependencies with the outside world. It's all in their area of influence which makes achieving short term results relatively easy. I'm referring to silo applications where the world is complicated enough. From their view, SOA makes things even more complex. There should be awareness that there is lack of knowledge, experience and attitude and something should be done about this first. There is no real solution, except for the obvious one: educate everyone involved. Also, agile methodologies have proven to be effective in building up knowledge and experience.
(more...)

Filed under: Agile, Architecture, SOA
4 Comments

Last week Rik de Groot published the #9: Versioning. This week it's time for #8.

SOA security is like having a well-protected Middle Ages city, but at the same time asking citizens to permit many more people from inside and outside the city into their homes. They would really have hard time properly securing their belongings.
Introduction of SOA should be accompanied by at least SPRINT business impact assessment of security vulnerabilities (confidentiality, data integrity and availability) and definition of required measures. Introduction of SOA also requires rethinking your security architecture.
(more...)

Filed under: SOA, Security
2 Comments

It is always about well-defined requirements stupid. Building or choosing out-of-the-box software products like an ESB within the company's SOA strategy can be very well supported by a number of requirements distilled from the QUINT2 ISO model:

Functionality: Suitability, Interoperability, Compliance, Security, Traceability
Usability: Operability, Customisability
Efficiency: Time Behaviour
Maintainability: Testability, Manageability, Reusability
Portability: Adaptability, Replaceability

This is the selection from the complete QUINT2 model. It does not mean that other requirements are not important, but usually less than these. If you fill out these requirements properly, which is still a daunting task, then you will have done pretty good requirements gathering. Besides these aspects, there are also security requirements: availability, integrity and confidentiality which should always be considered.

(more...)

Filed under: Requirements Management, SOA
1 Comment

This is a short and sharp conversation over ICQ between two Xebians about what an Agile Architect is or does. The conclusion is that an Agile Architect has, in addition to Agile manifesto, a number of principles:
- Just-in-time and just-enough architecture
- An architect is a "waste" and has no direct business value.
- An architect should have or make a business case about his value for the team.
- An architect spends more time in facilitation of good ideas and matching these with the business and enterprise aspects than defining one by herself.
- An architect emphasises "what" is needed above "how" should be achieved.

(more...)

Filed under: Agile, Architecture
3 Comments

Requirements engineering and design of services that your company need to provide to other companies is quite different from reqs. engineering for an interactive website, or other systems where an actor is a real person. In case of B2B services, the actor is always another system. Mostly you also know who your actors / other companies will be, unless you are Amazon or Google.
These recommendations will give you some tools and ideas how to deal with requirements engineering and design of B2B services.

(more...)

Filed under: Requirements Management, SOA
No Comments

Technical experts are often hired to fix some problem which hasn't been solved after spending huge amounts of time and money. An example could be trying to integrate legacy code with an object-oriented environment. The expert will typically try to address all mentioned problems. He uses his knowledge and experience to approach the problem in the most effective way. Experienced experts have many possible solutions and they choose the best one.

Wouldn't be much easier and cheaper for everyone if the first step in every single approach would be to ask: "How do we make this problem disappear?". It's funny to find out that almost everyone involved already knows the answer, but those who considered it didn't have the courage to propose it. Why? It's often because too much money is already spent on a problem which shouldn't be there in the first place, especially by the people involved. This is maybe the main reason why external audits are so important.

This happens quite often in J2EE world. For instance a less experienced technical team is asked to write use-cases. The lead developer / architect decides to develop a "state-of-the-art" framework for all future problems, not just this one, just in case someone should be needing it. This team will have one certainty: the more you want, the more problems you will generate, until you spend lots of effort on technical problems that weren't even requested by the customer...

Filed under: General
No Comments