Once a jobbing developer I have since moved into Management. I continue with a couple of hobby projects to ensure I don't go mad. I focus on iOS/Swift and ROR.
Used to do DevOps before they even called it that way: Linux. Python. Perl. Java. Docker. For fun and profit. CTO level generalist working for a mid-sized tech-centric company.
Dresden, Germany
Yes, that seems a valid approach that could work. Or, another approach somewhere in between DevOps and "Agile":
Make all these teams responsible (technically, economically) for the service they offer.
Give them some "manager", something like a Scrum Product Owner maybe, to do the coordination of which changes need to be implemented both in responding to "customer" request (with "customers" mostly being other teams) and in responding to issues found in operating the service.
Make sure these structures are known well internally so people know who they have to talk to in order to get what they need.
That's the road we're at the moment trying to take, unsure how well it will work. So far we have at least seen this "not fail" with companies around, though of course it has more than just a few pitfalls. At the moment, I am still watching and observing people who try to do right this, especially having the question of technical governance in mind as I still do think this is an approach that only works for a very specific kind of application environments - or companies. Not even talking about cultural changes in a company when trying to establish something like that after having been in operation for a couple of years... ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
IMHO
There are 2 groups of people that are a must to achieving an SOA.
a] An active and respected Technical Architecture Group
b] Clear governance bodies that oversee the Services and applications
If you have both of these groups (and the technical knowhow) then SOA can be achieved in a controlled and planned manner*.
Yes, that seems a valid approach that could work. Or, another approach somewhere in between DevOps and "Agile":
Make all these teams responsible (technically, economically) for the service they offer.
Give them some "manager", something like a Scrum Product Owner maybe, to do the coordination of which changes need to be implemented both in responding to "customer" request (with "customers" mostly being other teams) and in responding to issues found in operating the service.
Make sure these structures are known well internally so people know who they have to talk to in order to get what they need.
That's the road we're at the moment trying to take, unsure how well it will work. So far we have at least seen this "not fail" with companies around, though of course it has more than just a few pitfalls. At the moment, I am still watching and observing people who try to do right this, especially having the question of technical governance in mind as I still do think this is an approach that only works for a very specific kind of application environments - or companies. Not even talking about cultural changes in a company when trying to establish something like that after having been in operation for a couple of years... ;)