Many organisations in The Netherlands are culturally consensus based, which means there's often no clear leadership, management is often seen as purely facilitating and everybody more or less goes his or her own way. It's basically the way we (the Dutch) are.
Leadership is resisted. The boss says 'Let's do this my way', and there's bound to be a lively discussion about 'better' ways to do it. Everybody (boss included) accepts this as normal behaviour.
One of the hard parts of applying architecture in such a culture is to get everybody following the strategy as it is set out in the Enterprise Architecture. How are you going to do that if leadership is resisted? What happens? A lot of architectural implementations fail due to resistance from projects.
The introduction of Agile development has increased this problem. An often heard complaint is that too much upfront architecture is a form of over-specification, which is waste in agile terms. That's true, but the argument is too often used to totally ignore architecture and just focus on the user stories for this sprint. This can result in well working applications, which do not quite fit in the strategic direction of the company. Talking about waste ...
I'm not quite sure where the solution to this problem is. One way is to define architecture in such a way that there's something in it for everybody, not just for 'the business' or 'the architect'. Another way is to evangelize, to become a thought leader within the company. Not to push the architecture through, but to convince, stimulate and enthuse all participants.
Showing posts with label agile architecture. Show all posts
Showing posts with label agile architecture. Show all posts
Wednesday, 19 October 2011
Tuesday, 4 May 2010
Architecture and Agility
Last night I had an inspiring dinner with one of my old colleagues, Ronald Doelen. We both see more and more companies changing their project methodology from waterfall to agile. We're both very enthusiastic about that, even though there are some hurdles to take, like architecture for example.
All and good to go Agile, but if you're stuck in an analysis-paralysis situation with your architecture, you will not reap the benefits that Agile brings. You might get away with ignoring the architecting issue - at least for the short term - but it will catch up with you in due course.
So, the answer: Agile Architecture. That got a nice ring to it, but what and how? It all depends on how you look upon architecture and the role of the architect in the company. At the end of our meal - not quite as good as our discussion, tbh - we came up with a number of statements that we'll take with us to work on in the near future. Let me share a few of our thoughts:
The role of the architect in your organization is often determined by the culture of your organization. The architectural style (ivory tower, magician, counsellor, architectus reloadus) determines how you need to adapt your agile projects to align with architecture. The more agile the architect, the less impact.
Architecture is nothing more (or less) than a (limited!) set of choices and the accompanying motivations. Often architects worry about making the best choice. In case you didn't know it yet: there IS NO BEST CHOICE! There's just choices, all with consequences. Use risk-analysis to determine short and long term implications of your choices and base your trade-offs on them. But limit the choices to those you really need NOW.
I'll spend some more time thinking about Agile architecture and especially how to align Enterprise Architecture with Agile projects. I still see some challenges, but will take about those later.
All and good to go Agile, but if you're stuck in an analysis-paralysis situation with your architecture, you will not reap the benefits that Agile brings. You might get away with ignoring the architecting issue - at least for the short term - but it will catch up with you in due course.
So, the answer: Agile Architecture. That got a nice ring to it, but what and how? It all depends on how you look upon architecture and the role of the architect in the company. At the end of our meal - not quite as good as our discussion, tbh - we came up with a number of statements that we'll take with us to work on in the near future. Let me share a few of our thoughts:
The role of the architect in your organization is often determined by the culture of your organization. The architectural style (ivory tower, magician, counsellor, architectus reloadus) determines how you need to adapt your agile projects to align with architecture. The more agile the architect, the less impact.
Architecture is nothing more (or less) than a (limited!) set of choices and the accompanying motivations. Often architects worry about making the best choice. In case you didn't know it yet: there IS NO BEST CHOICE! There's just choices, all with consequences. Use risk-analysis to determine short and long term implications of your choices and base your trade-offs on them. But limit the choices to those you really need NOW.
I'll spend some more time thinking about Agile architecture and especially how to align Enterprise Architecture with Agile projects. I still see some challenges, but will take about those later.
Monday, 22 June 2009
ODTUG Update: SOA Symposium
Yesterday at 8 pm we started the SOA Symposium at ODTUG (yes, Sunday and Father's Day to boot). ODTUG is well known for its technological content, but as SOA becomes more and more mainstream, SOA will become a integral part of ODTUG.
The symposium was organized by three Dutch Oracle Ace Directors: Lonneke Dikmans, Lucas Jellema and myself. The setup we choose was a little different then one would expect from a symposium. From the start, we aimed to get a very interactive symposium where the goal is to meet other SOA adepts and to exchange experiences. We managed to achieve this by doing just 3 presentations (to create a mindset) followed by two workshops and a panel discussion.
The day was divided in two parts. In the morning we approached SOA from a business point of view, in the afternoon we discussed technology. The average knowledge level and experience of the participants was rather high, which made discussions very very interesting. It was good to see that there were a lot of Oracle Ace Directors present.
We've made several very interesting conclusions which will be put on the Oracle Wiki.
The symposium was organized by three Dutch Oracle Ace Directors: Lonneke Dikmans, Lucas Jellema and myself. The setup we choose was a little different then one would expect from a symposium. From the start, we aimed to get a very interactive symposium where the goal is to meet other SOA adepts and to exchange experiences. We managed to achieve this by doing just 3 presentations (to create a mindset) followed by two workshops and a panel discussion.
The day was divided in two parts. In the morning we approached SOA from a business point of view, in the afternoon we discussed technology. The average knowledge level and experience of the participants was rather high, which made discussions very very interesting. It was good to see that there were a lot of Oracle Ace Directors present.
We've made several very interesting conclusions which will be put on the Oracle Wiki.
Monday, 15 June 2009
Accessing Oracle SOA documentation
Ever tried to find that one document about the ESB on OTN? Did you quite remember where you found that BPEL Developers Guide? Well, life's been made easy for you. Marc Kelderman (Oracle Consulting) has made a list of just about all you need to start out with SOA from an Oracle perspective. Go and have a look at Marc Kelderman's shortlist. Way to go, Marc!
Wednesday, 3 June 2009
SOA: Process driven, message driven or event driven?
For a long time I thought that SOA is process driven, meaning that the functional requirements were discovered by working downwards from a business process perspective to a comprehensive set of services to deliver the business value.
However, the more solutions I see, the less I believe it. Saying so, I realize I need to clarify that a bit more. Whenever you're building an SOA from the Business process downwards, it is smart to discover possible candidate services from your existing legacy environments (building upwards) so you can execute a 'meet in the middle approach'. This usually results in orchestrating business processes (with BPEL) and -simplified - composing composite services (based on atomic services from your legacy).
Is that bad? Not in itself, I think. It depends on the type and the number of processes. Suppose you have - on average - 50.000 running instances of a process. If you have to change that BPEL process you defined, what will you do? The first question to answer is: what do I need to do with my current active processes? Can they continue using the existing process or do the need to switch? Does it depend on the state they are in or not?
This problem gets worse the longer a process runs. It increases the chance that a process change will occur during the time it runs. Besides, not only functional changes impacts the running processes, but an update of the underlying BPEL engine may do so as well. Of course, if the number of instances increases, your problem gets worse too. Ever tried to restart a BPEL engine with 150.000 instances?
If it's a short running process, you could stop all incoming transactions for the specific process and wait for the running processes to finish before you upgrade the process to it's new version. Unfortunately life is usually not that simple.
Let's get back to the initial thought: is an SOA process driven or not? If you follow the scenario I sketched above, you might end up with one that is. What you should keep in mind while designing an SOA application, is that you have to look ahead to see what possible situations you need to able to handle. If you know beforehand that you will have a (very) large number of active processes, that they will be long-running and that they will very likely be subject to change, you might want to consider a different approach. Why? Because migrating running processes in a BPEL environment is a very hard thing to do (and expensive too). You will need to make allowances in your architecture to prevent problems.
In that scenario, a more event-driven or message-driven approach may be the answer. By loosely coupling the stages a process will go through, using either events or messages, you are a lot more flexible when it comes to migrating to new versions of a process(step). This will mean that your 'highest level' process will probably not be visible as a process in your BPEL engine, but the underlying steps may be. Again depending on the duration of the processes.
However, the more solutions I see, the less I believe it. Saying so, I realize I need to clarify that a bit more. Whenever you're building an SOA from the Business process downwards, it is smart to discover possible candidate services from your existing legacy environments (building upwards) so you can execute a 'meet in the middle approach'. This usually results in orchestrating business processes (with BPEL) and -simplified - composing composite services (based on atomic services from your legacy).
Is that bad? Not in itself, I think. It depends on the type and the number of processes. Suppose you have - on average - 50.000 running instances of a process. If you have to change that BPEL process you defined, what will you do? The first question to answer is: what do I need to do with my current active processes? Can they continue using the existing process or do the need to switch? Does it depend on the state they are in or not?
This problem gets worse the longer a process runs. It increases the chance that a process change will occur during the time it runs. Besides, not only functional changes impacts the running processes, but an update of the underlying BPEL engine may do so as well. Of course, if the number of instances increases, your problem gets worse too. Ever tried to restart a BPEL engine with 150.000 instances?
If it's a short running process, you could stop all incoming transactions for the specific process and wait for the running processes to finish before you upgrade the process to it's new version. Unfortunately life is usually not that simple.
Let's get back to the initial thought: is an SOA process driven or not? If you follow the scenario I sketched above, you might end up with one that is. What you should keep in mind while designing an SOA application, is that you have to look ahead to see what possible situations you need to able to handle. If you know beforehand that you will have a (very) large number of active processes, that they will be long-running and that they will very likely be subject to change, you might want to consider a different approach. Why? Because migrating running processes in a BPEL environment is a very hard thing to do (and expensive too). You will need to make allowances in your architecture to prevent problems.
In that scenario, a more event-driven or message-driven approach may be the answer. By loosely coupling the stages a process will go through, using either events or messages, you are a lot more flexible when it comes to migrating to new versions of a process(step). This will mean that your 'highest level' process will probably not be visible as a process in your BPEL engine, but the underlying steps may be. Again depending on the duration of the processes.
Thursday, 9 April 2009
ODTUG SOA/BPM Symposium
Ever hear of the ODTUG Kaleidoscope? It's the yearly conference that's organized by the Oracle Developers Technical User Group (ODTUG). This year there will be a number of symposiums at the day before ODTUG starts.
One of them is the SOA & BPM Symposium, that's organized by Lonneke Dikmans, Lucas Jellema and myself. It will not be your average symposium. It will be a very interactive meeting of minds. The symposium is about working together, exchanging experiences and trying to determine the best, most practical way, to go about implementing an SOA.
So, if you feel you have anything useful to bring to the table or you want to hear what recognized specialists in the industry do and think, why not join us at the ODTUG SOA/BPM Symposium?
This symposium is organized by a large number of Oracle ACE Directors. Expect a large number of them to be there and participate actively! Come and join us!
One of them is the SOA & BPM Symposium, that's organized by Lonneke Dikmans, Lucas Jellema and myself. It will not be your average symposium. It will be a very interactive meeting of minds. The symposium is about working together, exchanging experiences and trying to determine the best, most practical way, to go about implementing an SOA.
So, if you feel you have anything useful to bring to the table or you want to hear what recognized specialists in the industry do and think, why not join us at the ODTUG SOA/BPM Symposium?
This symposium is organized by a large number of Oracle ACE Directors. Expect a large number of them to be there and participate actively! Come and join us!
Subscribe to:
Posts (Atom)