Aggregated enterprise architecture wisdom
By The Open Group It’s no secret that the IT workforce is suffering from a skills gap. Not only are there not enough workers available to fill tech positions at many companies, but even the workers available may not possess … Continue reading →
DevOps, in its intention to integrate IT Development and Operations, demands in fact that IT Operations become as agile as the Development.
DevOps, in its intention to integrate IT Development and Operations, demands in fact that IT Operations become as agile as the Development.
According to definitions though, Two Speed IT and Bimodal IT appear to be the same concept for all intent and purpose.
According to definitions though, Two Speed IT and Bimodal IT appear to be the same concept for all intent and purpose.
Maybe it’s a sign. Although I haven’t made New Year’s predictions in the past, this year I took part in a panel discussion with Jeremy Berriault, Steve Tendon, Kim Pries, hosted by Tom Cagley for his SPaMCast podcast (it should be posted this weekend, I’ll link to it when it does). As Tom described it […]
Much has been written about the potential benefits of designing applications using microservices. A fair amount has also been written about the potential pitfalls. On this blog, there’s been a combination of both. As I noted in “Are Microservices the Next Big Thing?”: It’s not the technique itself that makes or breaks a design, it’s […]
IT is not really about investigating the emerging Digital technologies landscape, their adoption strategy and roadmapping.
…never mind IT, to survive, most our enterprises are rather bimodal. But I would no call them that, Bimodal enterprises, it sounds too clinical.
By The Open Group 1 Title/Current Version IT4IT™ Reference Architecture Version 2.0, an Open Group Standard 2 The Basics The Open Group IT4IT Reference Architecture standard comprises a reference architecture and a value chain-based operating model for managing the business … Continue reading →
A frequent question I get from data management and governance teams is how to stay ahead of or on top of the Agile development process that app dev pros swear by. New capabilities are spinning out faster and faster, with little adherence to ensuring compliance with data standards and policies.
Well, if you can’t beat them, join them . . . and that’s what your data management pros are doing, jumping into Agile development for data.
Forrester’s survey of 118 organizations shows that just a little over half of organizations have implemented Agile development in some manner, shape, or form to deliver on data capabilities. While they lag about one to two years behind app dev’s adoption, the results are already beginning to show in terms of getting a better handle on their design and architectural decisions, improved data management collaboration, and better alignment of developer skills to tasks at hand.
But we have a long way to go. The first reason to adopt Agile development is to speed up the release of data capabilities. And the problem is, Agile development is adopted to speed up the release of data capabilities. In the interest of speed, the key value of Agile development is quality. So, while data management is getting it done, they may be sacrificing the value new capabilities are bringing to the business.
Let’s take an example. Where Agile makes sense to start is where teams can quickly spin up data models and integration points in support of analytics. Unfortunately, this capability delivery may be restricted to a small group of analysts that need access to data. Score “1” for moving a request off the list, score “0” for scaling insights widely to where action will be taking quickly.
A frequent question I get from data management and governance teams is how to stay ahead of or on top of the Agile development process that app dev pros swear by. New capabilities are spinning out faster and faster, with little adherence to ensuring compliance with data standards and policies.
Well, if you can’t beat them, join them . . . and that’s what your data management pros are doing, jumping into Agile development for data.
Forrester’s survey of 118 organizations shows that just a little over half of organizations have implemented Agile development in some manner, shape, or form to deliver on data capabilities. While they lag about one to two years behind app dev’s adoption, the results are already beginning to show in terms of getting a better handle on their design and architectural decisions, improved data management collaboration, and better alignment of developer skills to tasks at hand.
But we have a long way to go. The first reason to adopt Agile development is to speed up the release of data capabilities. And the problem is, Agile development is adopted to speed up the release of data capabilities. In the interest of speed, the key value of Agile development is quality. So, while data management is getting it done, they may be sacrificing the value new capabilities are bringing to the business.
Let’s take an example. Where Agile makes sense to start is where teams can quickly spin up data models and integration points in support of analytics. Unfortunately, this capability delivery may be restricted to a small group of analysts that need access to data. Score “1” for moving a request off the list, score “0” for scaling insights widely to where action will be taking quickly.