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
Ah. Nice. Now that's a completely different beast to tame I guess. Around here, this is not so much of an issue as there aren't that many teams and coupling between their components is pretty loose so of course there are problems but they aren't as massive as they possibly would be with all these folks working on a single code base in a monolith. ;) What are the biggest political issues you're facing there? API contracts? Deployment and uptime issues? I can imagine a few things...
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
Ok, this is pretty much what I thought. The only reason we didn't completely get lost within this is a mere matter of (lack of) size. Asides that, it shows rather well in my opinion that introducing changes such as DevOps, microservice architecture and the like will never really work out if they are limited to the technical staff and leave out management teams and team objectives. This seems a way more complex and difficult task to do well...
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.
Ah. Nice. Now that's a completely different beast to tame I guess. Around here, this is not so much of an issue as there aren't that many teams and coupling between their components is pretty loose so of course there are problems but they aren't as massive as they possibly would be with all these folks working on a single code base in a monolith. ;) What are the biggest political issues you're facing there? API contracts? Deployment and uptime issues? I can imagine a few things...
I don't have any problems at the moment. It was just a comment from previous experiences.
But to add more detail....
Lets say you have a service, S1, that is provided by a division of the business D1 and used by divisions D1 and D2.
Now suppose that D2 needs a new api end point that provides an alternate format of data, or some other change to the service S1.
Suddenly D2 need to get D1 on side and persuade them to make the change they need.
D1's budgets and priorities are unlikely to be aligned to D2.
This can be the biggest problem.
Ok, this is pretty much what I thought. The only reason we didn't completely get lost within this is a mere matter of (lack of) size. Asides that, it shows rather well in my opinion that introducing changes such as DevOps, microservice architecture and the like will never really work out if they are limited to the technical staff and leave out management teams and team objectives. This seems a way more complex and difficult task to do well...
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... ;)