Jumping straight into SOA often does not work. This is related to Conway's Law that the people architecture at a company affects the code writing architecture. To get to SOA, you need to refactor the people architecture of your company as well, over time. The boundaries of progress moving toward an SOA business are note always clearly defined. Phase 0 is: big ball of mud, everything overlapping, etc. This mess has taken people at the organization a long time to create and lots of it works. Trying to replace the whole thing will probably fail. Conversation, however, about rewrites are healthy. It implies that "we need to do something different". Slowly improve things that still have business value and allow a "tax" on top of each feature to improve the structure of the system overall. Phase 1
Don't go apply this to the next mission-critical system. Try something small to get your feet wet. Get the first queue in production.
Ops: new stuff, but not very much of it (one queue)
Dev: very low, one message handler, refactor a small system
Org: mostly dev organization, getting them used to SOA principles. You can do lunch and learns, workshops, etc. Get developers to care, wanting good quality code, care about their craft. Once you get there, they start saying things like "it would be easier and faster to rewrite this!".
|
|
|
|
| Ops |
Dev |
Org |
Duration |
| Medium |
Low |
Lunch & Learns, Workshops, etc |
6 months (small, young companies) to 12 months (bigger companies) |
| Phase 2 |
|
|
|
| Starting to see belief that things can actually change--there's hope! Choose to deliver functionality to the business over making unnoticeable changes--you have to keep the value apparent and the budget there. You may start risking breaking stuff here. You start at the end of each use case, to publish events. You're creating hooks, even if you don't know what they'll do yet. Doesn't HAVE to be a bus message. Could be something as ugly as writing to tables that others are looking at. You're just trying to get the concept of events a common practice. If you come across functionality that could be improved and done easier with subscribers (let's say also using signalr to update a user in their interface that gives extra business value). You're not worrying about service boundaries or data duplications...etc. You're trying to show the business that things are starting to pay off. Using the "new way" is making things faster and better. You need to keep the feeling of momentum. Most of the work is still being done in the big ball of mud to maintain it and keep it going. You want to have a good, small core of people on board with the changes to start planning things out and looking ahead. We want to do SOA! The work by this group is quiet and off to the side. A couple of hours here and there from a real domain expert. You're asking the domain expert for a few hours every-so-often to ask questions, verify your vision--starting to find the service boundaries. You're not yet sharing this with the larger organization. You're trying to get a general direction for your services--not having to know exactly what they look like yet, but being pretty sure it's in "this" direction. |
|
|
|
|
|
|
|
| Ops |
Dev |
Org |
Duration |
| Med |
Med |
Learning and practice UI composition techniques, pub/sub patterns, decoupling. Much more explicit training efforts. You are starting to want to know what you're creating. |
6 months - 18 months
If you don't feel you have the right momentum built up, wait--take your time. |
| Phase 3 |
|
|
|
| You're trying to get to the point of the business being willing to wait longer for new features. You start hacksawing the big ball of mud. You carve out a piece and add it to the subscriber where it makes the most sense. You have to be very careful with the data model. Some of this is changing things to composite UI stuff. It's difficult to be restabilizing the big ball of mud all the time--that's one of the hardest parts of this phase. The issue in the first place with the big ball of mud is that you don't know what changing any individual piece of the ball will effect. The SOA work from phase 2 is important because you need to know (at least basically) where you will be putting rewritten code. The small meetings about SOA are opening up to more executives. Your concept of the correct SOA is crystalizing. You're meeting with more domain experts and have the approval of executives to pull them into (probably) weekly meetings. You need to have good answers for all of the edge cases that business people care about (and need). That's what the big ball of mud is--the answer to a thousand edge cases identified over time. A large organization can end up stuck in phase 3. Right when you're getting to a good spot, they buy another company and now you need to integrate an entire new set of legacy systems. You can do this! You get it done in 12 months and...the CEO buys another company and you start all over again. Sometimes tech leadership leaves when they get frustrated that the vision will never happen. Momentum is important (almost at any cost) to break through to phase 4. |
|
|
|
|
|
|
|
| Ops |
Dev |
Org |
Duration |
| Low |
High |
SOA design is being clearer and clearer. You're training on what it means to work in an SOA environment. Don't be talking about things that are too far ahead. Be talking no more than things that are about 6 months ahead. |
12 months - 36 months |
| Phase 4 |
|
|
|
| Phase 4 is hard because you start dealing with data. You start chopping up the big, monolithic data into the service boundaries. You need to treat the data migration code as long-term code that you can run and rerun and that you will maintain just like product code. Ops effort is medium because there are new database, etc. You'll be writing code and building across multiple repositories. The big ball of mud is shrinking quicker than before. You're migrating data out and building services. You're completely out the rest of UI composition. You'll see lots of opportunities to make things better towards the tail end of phase 4. You can learn to live with it. |
|
|
|
|
|
|
|
| Ops |
Dev |
Org |
Duration |
| Medium |
High |
At some point, it will become clear that the way that teams are structured is hurting us. You'll hear "we need a reorg". The re-org will be along service boundaries. It should be clear to everyone at this point what the service boundaries are. Reorgs are hard and so you want enough momentum at this point to make it through. |
12 months - 36 months |
| Notes |
|
|
|
| Having a pattern of fallback to an old way (config to switch between new and old way) is a useful practice throughout all the phases. It makes us bolder to try new things because we can always immediately switch back to the old way. This helps with your momentum. Enough failures will lead to a loss of momentum. Having the immediate fallback makes the failure less noticeable (if at all). You can be assured that things will never be worse than they were before. A good metaphor is rock-climbing. Every time you make a certain distance, you hammer in an anchor. If you fall, you only fall so far. The percentage of our work that is dedicated to clean-up and refactoring should never be over 30%! OUR JOB is to deliver business value to the business. Trade-offs never stop. A healthy state of things is to always be seeing where the improvements can happen. |
|
|
|
