I think the idea of building enterprise architectures is a great ideal. It relates very closely to the idea of project portfolio management – where multiple projects are coordinated as a hole for the benefit of the enterprise. Here are some of the ideas based on experience at the US Army.  This topic is sure to be revisited!
1. The challenge is the process the organization uses to develop and implement the architectures. This process, interestingly, is a carefully crafted project plan which is repeatable and ‘tweak-able’. The organization must rethink some of its organizational practices. For example, having ’silos’ produce the architecture means that the architects are not optimally connected to the organization. Everyone must buy into a cohesive vision, and implement that within the organization. And it can be very difficult, maybe impossible, to get everyone to buy in to one way of actually doing it. Tools must be flexible, but the vision needs to be firm.
3. ‘Flexible and responsive’ are not usually terms used in the same sentence with ‘government’ - so expectations need to be managed accordingly. There can be a vast network of approval processes built on a less than agile paradigm, and funding is a challenge.
4. One of the major problems in large organizations is having a system that integrates well across a vast network of sub-organizations. If there are multiple programs being used to build architectures, something is lost in efficiency in the translations. ‘Flexibility’ of the architecture package and interoperability with other tools is critical!!!
5. I think the alignment can happen as described, but it takes a lot of vision sharing, some restructuring, paradigm shifts, and leadership.
6. I think enterprise architecture can increase capacity to deliver in the face of decreasing IT budgets.
7. The architecture process must be tied to natural cycles. To be relevant, it must align schedule-wise with the realities of development and test cycles, fielding cycles, update and patch requirements, etc; it cannot be a one time - or periodic - event, but rather needs to be a regular part of the continuing lifecycle of projects.
8. Developing quality IT architecture well can serve to identify repetitive development processes, reducing custom development.
9. I would have a lot of concerns for medium and smaller size organizations building the infrastructure to support this. It requires commitment from the top, but also requires significant investment in enabling software as well as resources.
10. Shortening the lifecycle involves much, much more in terms of management than just employing an architecture/requirements management system. It involves cultural change, paradigm shifts, and organizational realignment.
0 responses so far ↓
There are no comments yet...Kick things off by filling out the form below.
You must log in to post a comment.