Perhaps when you really think about the end-all and be-all purpose of service oriented architecture, it all boils down to one important thing: the need for scalability. Not scalability in the sense that we usually think about it - throwing massive processing power and hardware at a problem to keep applications running fast and furious -- but in the ability of organizations to grow and adapt.
The best way to achieve greater scale is to unleash the innovation and creative juices that can flow from small, highly focused teams -- not through huge, unwieldy mega-projects. But how do you manage a process driven by such diverse groupings?
As Miko Matsumura puts it, SOA needs to be repurposed, to bring all the "tribes" that exist across a typical enterprise into a common purpose, while retaining their independence. SOA has its benefits, but this may be the most significant and lasting benefit of the SOA exercise. Miko and I recently explored this perspective in a podcast now available here at ebizQ. (Listen to the podcast here, or read the transcript here.)
"When I talk about scalability computing, the thing that leaps to everyone's mind is they think about like, oh, what about transaction speed," Miko explains. "And particularly as I stand as a spokesperson for Software AG, who happens to sell the world's fastest online transactional processing database (Adabas Mainframe) products. I want to talk about scalability of computing from a different perspective, which is perspective of teams. What I mean by scalability teams is that think about the size of a software project."
In the podcast, Miko and I explored how SOA enables managers to do a lot more software development and deployment across the enterprise with fewer resources than under the pre-SOA model. The challenge, Miko explains, is that as IT projects grow in scope and complexity, they end up being split between various "tribes" within the organization.
Teams of up to seven people usually are quite effective for smaller and cutting-edge software projects, Miko says. But what happens when these projects grow in scope and size? "If you get the slightly bigger projects you get what I called 'tribal computing,'" Miko says. "And tribal computing is where things get really interesting because what happens is that when you get to a certain size, organizational designers have what they call magic number -- roughly 150 or so people. The reason why 150 is a magic number is when you actually look at layers of an organization, you assume that people can only manage sort of seven plus or minus a few other people. You start to get to the point where there's almost like a three-layer hierarchy and what this does is it causes human groups to cleave into tribes."
Tasks with managing large, unweildy IT projects, such "tribes" end up working at cross-purposes -- splitting into divisions, business units, functional units, geographic units, and platform units -- such as Java, Oracle, Microsoft, and SAP professionals, Miko says. "Programmers involved in these tribes tend to scale of resolution sort of become self interested, combative, political and otherwise difficult."
The rise of cloud computing -- and a movement to return to the basics of SOA -- have given rise to a sense of excitement, that changes in the organization can be driven by small, highly focused teams. "Some of these tribes in IT have experienced enough attrition that they've actually been reduced to small team size again," Miko points out. "So, just attrition and loss of head count has reduced the bulkiness, and the bureaucracy, and the heavy weightiness of enterprise IT to the point where instead of once again lean and mean, and looking for solutions."
"Compress your teams into four to seven individuals, which I think is a beautiful scale for software development," Miko continues. "Four to seven developers has changed the world scale. That's an awesome size for a team."
A well-functioning service-oriented architecture -- with governance and lifecycle mechanisms in place -- can help capture and channel the energy generated by these highly mobile and entrepreneurial teams. "So I think that there's still a need for a coordination mechanism that helps manage contracts, it helps manage trust, it helps manage this idea of composition, and how this element of compute landscape talk to each other, and how they snap together, and how they create the big picture, and the big puzzle," Miko says.
(Listen to the podcast here, or read the transcript here.)
The best way to achieve greater scale is to unleash the innovation and creative juices that can flow from small, highly focused teams -- not through huge, unwieldy mega-projects. But how do you manage a process driven by such diverse groupings?
As Miko Matsumura puts it, SOA needs to be repurposed, to bring all the "tribes" that exist across a typical enterprise into a common purpose, while retaining their independence. SOA has its benefits, but this may be the most significant and lasting benefit of the SOA exercise. Miko and I recently explored this perspective in a podcast now available here at ebizQ. (Listen to the podcast here, or read the transcript here.)
"When I talk about scalability computing, the thing that leaps to everyone's mind is they think about like, oh, what about transaction speed," Miko explains. "And particularly as I stand as a spokesperson for Software AG, who happens to sell the world's fastest online transactional processing database (Adabas Mainframe) products. I want to talk about scalability of computing from a different perspective, which is perspective of teams. What I mean by scalability teams is that think about the size of a software project."
In the podcast, Miko and I explored how SOA enables managers to do a lot more software development and deployment across the enterprise with fewer resources than under the pre-SOA model. The challenge, Miko explains, is that as IT projects grow in scope and complexity, they end up being split between various "tribes" within the organization.
Teams of up to seven people usually are quite effective for smaller and cutting-edge software projects, Miko says. But what happens when these projects grow in scope and size? "If you get the slightly bigger projects you get what I called 'tribal computing,'" Miko says. "And tribal computing is where things get really interesting because what happens is that when you get to a certain size, organizational designers have what they call magic number -- roughly 150 or so people. The reason why 150 is a magic number is when you actually look at layers of an organization, you assume that people can only manage sort of seven plus or minus a few other people. You start to get to the point where there's almost like a three-layer hierarchy and what this does is it causes human groups to cleave into tribes."
Tasks with managing large, unweildy IT projects, such "tribes" end up working at cross-purposes -- splitting into divisions, business units, functional units, geographic units, and platform units -- such as Java, Oracle, Microsoft, and SAP professionals, Miko says. "Programmers involved in these tribes tend to scale of resolution sort of become self interested, combative, political and otherwise difficult."
The rise of cloud computing -- and a movement to return to the basics of SOA -- have given rise to a sense of excitement, that changes in the organization can be driven by small, highly focused teams. "Some of these tribes in IT have experienced enough attrition that they've actually been reduced to small team size again," Miko points out. "So, just attrition and loss of head count has reduced the bulkiness, and the bureaucracy, and the heavy weightiness of enterprise IT to the point where instead of once again lean and mean, and looking for solutions."
"Compress your teams into four to seven individuals, which I think is a beautiful scale for software development," Miko continues. "Four to seven developers has changed the world scale. That's an awesome size for a team."
A well-functioning service-oriented architecture -- with governance and lifecycle mechanisms in place -- can help capture and channel the energy generated by these highly mobile and entrepreneurial teams. "So I think that there's still a need for a coordination mechanism that helps manage contracts, it helps manage trust, it helps manage this idea of composition, and how this element of compute landscape talk to each other, and how they snap together, and how they create the big picture, and the big puzzle," Miko says.
(Listen to the podcast here, or read the transcript here.)
Relgolook is a productivity application for Microsoft outlook users. Relgolook information management provides organize and archive emails and information and reduce attrition