How to evaluate multiple software platforms for consolidation
August 20, 2015 10:51 AM Subscribe
"Help me do my job" filter.
I work for a tech company, as a software developer/manager. Our group (a dozen people or so, including the managers/senior developers) has recently merged with another, and between us we now have a lot of "core platform" technology that is duplicated across all the varied products (think - user authorization/authentication, user preference storing, file validation, core business tasks like matching names to identifying numbers).
And now we want to consolidate these so there is only 1 piece of software doing the core platform work. How do we do this?
Take the user authorization/authentication as an example. My team has an implementation, the other team has several implementations specific to several of their products. We're all one big team now, and want to stop supporting multiple pieces of software that do the same work. How do we effectively evaluate each piece for its pros/cons, and how do we plan for migration/writing-a-new-one?
Current thoughts include:
* demo (at a low level, appropriate for developers) each platform - how it works, where it lives, where it logs, how its monitored, who supports it, etc to each other - and at the same time generate a standard document with that same information
* managers meet, having reviewed the documents previously created and..... "figure it out"
* possible outcomes are - we all move to product A's implementation, with minor improvements/adjustments/add-ons to it, so that accomodates the specific needs of products B through Z. OR we decide that no one's implementation is ideal, and start a new one from scratch (bleh, I don't think anyone actually thinks that would be a good idea, but we are keeping options open)
But what else are we missing here, or what - more specifically - goes into the "figure it out" step.
Looking for - anecdotal "this worked for us" stories, links to helpful pages, step by step evaluation instructions, pretty much anything and everything that might relate to evaluating multiple platforms with an eye toward consolidation?
Take the user authorization/authentication as an example. My team has an implementation, the other team has several implementations specific to several of their products. We're all one big team now, and want to stop supporting multiple pieces of software that do the same work. How do we effectively evaluate each piece for its pros/cons, and how do we plan for migration/writing-a-new-one?
Current thoughts include:
* demo (at a low level, appropriate for developers) each platform - how it works, where it lives, where it logs, how its monitored, who supports it, etc to each other - and at the same time generate a standard document with that same information
* managers meet, having reviewed the documents previously created and..... "figure it out"
* possible outcomes are - we all move to product A's implementation, with minor improvements/adjustments/add-ons to it, so that accomodates the specific needs of products B through Z. OR we decide that no one's implementation is ideal, and start a new one from scratch (bleh, I don't think anyone actually thinks that would be a good idea, but we are keeping options open)
But what else are we missing here, or what - more specifically - goes into the "figure it out" step.
Looking for - anecdotal "this worked for us" stories, links to helpful pages, step by step evaluation instructions, pretty much anything and everything that might relate to evaluating multiple platforms with an eye toward consolidation?
a fly-off is a terrible idea - especially if managers are scoring. what you are looking for is an evaluation of the code's amenability to change.
posted by j_curiouser at 11:12 AM on August 20, 2015 [1 favorite]
posted by j_curiouser at 11:12 AM on August 20, 2015 [1 favorite]
This is a big, hairy problem with both technical and political aspects to it. Depending on the size and complexity of your company, and how quickly you want this to happen, it's likely you need someone (or even more than one person) to manage this project as their main responsibility. I've seen these kinds of things take anywhere from a year to infinite time (as in, the project never gets completed). It's non-trivial unless the systems are simple and the company small.
Purely from a technical and product standpoint, I think you need to have someone do a deep analysis of the actual requirements of each system that uses the services. For example, authentication/authorization is a huge topic, and you could have ten implementations with almost no overlapping functionality that still call themselves auth services. You need to know what the real requirements are, so you can make sure you pick something that actually covers them (most likely you don't have a single service that covers all the use cases, so you'll need to build some stuff too). Sometimes "requirements" aren't really requirements, so you also need someone who can really dig into why each unique thing is needed, and figure out if there's some way to eliminate the requirement or statisfy it in another way. This exploration in and of itself can take a long time. Then at the end you'll probably have a bunch of work items to make the "chosen" system support all of the true requirements and port all of the dependent systems to use the new One True Service. Rinse and repeat for each set of services you want to eliminate. Remember that all of the time you dedicate to this will be time you're taking away from developing features for your customers, so you have to prioritize with that in mind. Sometimes some duplication is the right business decision even if it looks ugly from an engineering perspective.
The political aspect can be equally tricky depending on the people involved. A lot of people who have built a service aren't eager to give it up and let it be replaced by something that other people built. Ego, power, etc. Hopefully you don't have too many of those problems (sometimes it's helpful to pitch it as "hey, you don't have to waste time on this stuff any more, you can just focus on your actual product"), but be on the lookout for it.
Anyway, good luck!
posted by primethyme at 11:15 AM on August 20, 2015 [3 favorites]
Purely from a technical and product standpoint, I think you need to have someone do a deep analysis of the actual requirements of each system that uses the services. For example, authentication/authorization is a huge topic, and you could have ten implementations with almost no overlapping functionality that still call themselves auth services. You need to know what the real requirements are, so you can make sure you pick something that actually covers them (most likely you don't have a single service that covers all the use cases, so you'll need to build some stuff too). Sometimes "requirements" aren't really requirements, so you also need someone who can really dig into why each unique thing is needed, and figure out if there's some way to eliminate the requirement or statisfy it in another way. This exploration in and of itself can take a long time. Then at the end you'll probably have a bunch of work items to make the "chosen" system support all of the true requirements and port all of the dependent systems to use the new One True Service. Rinse and repeat for each set of services you want to eliminate. Remember that all of the time you dedicate to this will be time you're taking away from developing features for your customers, so you have to prioritize with that in mind. Sometimes some duplication is the right business decision even if it looks ugly from an engineering perspective.
The political aspect can be equally tricky depending on the people involved. A lot of people who have built a service aren't eager to give it up and let it be replaced by something that other people built. Ego, power, etc. Hopefully you don't have too many of those problems (sometimes it's helpful to pitch it as "hey, you don't have to waste time on this stuff any more, you can just focus on your actual product"), but be on the lookout for it.
Anyway, good luck!
posted by primethyme at 11:15 AM on August 20, 2015 [3 favorites]
Sent you a MeMail.
posted by invitapriore at 12:00 PM on August 20, 2015
posted by invitapriore at 12:00 PM on August 20, 2015
I have been on projects where two product teams merged and we decided we'd pick a winner for underlying functionality. Basically, you should assume that for the foreseeable future you're going to need all current auth/whatever systems to keep running. You shouldn't impose stupid deadlines like "well, by next financial qurter, we should all use the same auth library!". You should do the work of figuring out which one is 'best', or which one you'll pick for the long-term anyway, and then you should do exhaustive analysis of missing functionality in that, and then when updates need to be made to code calling auth library x, then you should try and migrate to the new Standard Library while you're touching the code anyway. You might say " no new feature development on the deprecated libraries," or that might be too restrictive, depends on how important they are to your products.
posted by the agents of KAOS at 4:09 PM on August 20, 2015
posted by the agents of KAOS at 4:09 PM on August 20, 2015
Well, first off you should consider that the other team has apparently existed just fine with multiple authentication systems for some time now, so are you sure they're really on board with going down to just one? (And are you sure they have the skill level to do the transition properly?)
You should also consider that if you've got a dozen people and they've got some non-trivial number of people, then you're dealing with quite a big team here. It might make sense as a first step to, say, create a small "authentication team" who owns all the authentication services, and that team maintains them while gaining experience on all the systems, and then would be in a better position to consolidate.
That said, if you do want to consolidate now, I don't think it's really worth writing up extensive docs for a bunch of systems which are mostly going to be deprecated (unless you need those docs for other reasons, like you're going to be taking over maintenance of systems you're unfamiliar with). What I would instead do is find the most senior person who is developer-familiar with each auth system, and ask them 1) is this a good system or a bad system? 2) what are the things this system does that are a going to be a pain to handle elsewhere? Experienced developers usually have pretty good intuition about these two questions, and if everyone agrees one of the auth systems is small and crappy there's no point considering it further.
Beyond that, I would suggest trying to make decisions based on principles and not based on specific systems. If the managers agree that the group language going forward is going to be java, then you don't want to pick a php system as the go-forward choice even if it's really well-written. It may be important to pick systems to get an overall coherent architecture, or it may not - you're going to be stuck with a frankenstein setup anyway if you're merging two groups. (And if you're still stuck beyond that, it probably doesn't matter which you pick, so choose based on politics, because a bunch of feelings are going to be hurt in this process and here's an opportunity to make a few people feel better.)
posted by inkyz at 9:54 PM on August 20, 2015
You should also consider that if you've got a dozen people and they've got some non-trivial number of people, then you're dealing with quite a big team here. It might make sense as a first step to, say, create a small "authentication team" who owns all the authentication services, and that team maintains them while gaining experience on all the systems, and then would be in a better position to consolidate.
That said, if you do want to consolidate now, I don't think it's really worth writing up extensive docs for a bunch of systems which are mostly going to be deprecated (unless you need those docs for other reasons, like you're going to be taking over maintenance of systems you're unfamiliar with). What I would instead do is find the most senior person who is developer-familiar with each auth system, and ask them 1) is this a good system or a bad system? 2) what are the things this system does that are a going to be a pain to handle elsewhere? Experienced developers usually have pretty good intuition about these two questions, and if everyone agrees one of the auth systems is small and crappy there's no point considering it further.
Beyond that, I would suggest trying to make decisions based on principles and not based on specific systems. If the managers agree that the group language going forward is going to be java, then you don't want to pick a php system as the go-forward choice even if it's really well-written. It may be important to pick systems to get an overall coherent architecture, or it may not - you're going to be stuck with a frankenstein setup anyway if you're merging two groups. (And if you're still stuck beyond that, it probably doesn't matter which you pick, so choose based on politics, because a bunch of feelings are going to be hurt in this process and here's an opportunity to make a few people feel better.)
posted by inkyz at 9:54 PM on August 20, 2015
« Older My email is in the Ashley Madision leak. Should I... | Waterproof mattress cover recommendations? Newer »
This thread is closed to new comments.
this can be quite the bitch, especially if you have a team that *thinks* they know OODD, versus actually knowing it. to generalize successfully will require a lot of abstractions and maybe a lot of extensibility.
if this were my charter...pick the most stable code base, then refactor to add support for other systems. one-at-a-time.
that's right - one-at-a-time. that's how the generalizations and abstractions will reveal themselves.
Truly reusable objects can not be designed through superior insight and sheer force of will.
posted by j_curiouser at 11:08 AM on August 20, 2015 [3 favorites]