Aggregated enterprise architecture wisdom
Please take a moment to check out the page I just posted, “Do You Have Two Minutes?”. It tells about an incredible young man who is battling cancer. I hope you’ll consider helping him out, but regardless, the time spent hearing about him would be well spent. -Gene
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 →
Enterprise Architecture is facing several challenges as a discipline and a practice. In this blog post, John Gøtze outlines four central challenges, and discusses what should be done. He suggests that enterprise architecture management must focus on enterprise collaboration. The Challenges The discipline Enterprise Architecture (EA) is at a crossroads, facing four challenges: The first […]
The team is in full swing now, very much aware of the fact that ‘the pressure is on’. The reference models are in a “good enough” form at the moment, and some of the grumbling from management seems to be fading away. Through informal channels, the team has learned that part of the frustration seems to come from the fact that an audit (“quick scan”) by an external party has resulted in advise to management to “speed things up a notch”. So much for careful planning!
By The Open Group This year marks the 20th anniversary of the first version of TOGAF®, an Open Group standard, and the publication of “The Boundaryless Organization,” a book that defined how companies should think about creating more open, flexible … 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.
In my last post, “Locking Down the Prisoners: Control, Conflict and Compliance for Organizations”, I returned to a topic that I’ve been touching on periodically over the last year, organizations as systems, which overlaps significantly with the topic of enterprise architecture (not to be confused with enterprise IT architecture of which EA is a superset). […]
Some architects may be familiar with Amdahl’s law that looks at the maximum improvement when only a part of the system can be optimised, as it is often used in parallel computing processing. The important part here of Amdahl’s law is to see that savings in part of a system usually will show that to … Continue reading Savings →
Srinidhi Boray | Ingine, Inc | Bioingine.com Introducing, Ingine, Inc. it is a startup in its incipient stages of developing BioIngine platform, which brings advancement in data science around Interoperability. Particularly with healthcare data mining and analytics dealing with medical knowledge extraction. Below are some of the lessons learned discussed while dealing with the healthcare […]
I’ve just finished writing a fascinating Report for Cutter Consortium about Business Patterns and EA. For some time now I’ve been working with EA practitioners who are taking advantage of information that has already been gathered by people from backgrounds other than EA. The EA role then becomes one of converting or translating this information…
In the book, I’ve written about several standard instruments of the orthodox enterprise architecture approach. One of these is the use of ‘architecture principles’. I’m convinced, personally, that these often do more bad than good and this has to do … Continue reading →