Excerpt from link
When project teams work under the assumption that they can do anything that they want, that they can use any technology that they want, chaos typically results. Functionality and information will be duplicated and reuse will occur sporadically if at all. Systems will not integrate well. Systems will conflict with one another and cause each other to fail. Costs will skyrocket because similar products from different vendors, or even simply different versions of the same product, will be purchased and then operated within production. Although each individual project may be very successful, as a portfolio they may have serious challenges. It doesn’t have to be this way. The cold reality is that very few software-based systems exist in a vacuum, instead they must co-exist with several and sometimes hundreds of other systems. Applications must co-exist effectively with the other systems within your organization. Therefore an application must minimally be developed so that it doesn’t cause adverse affects on your other systems and ideally it should be built to take advantage of and to enhance a shared infrastructure. Every system must be built so it can fit into your existing environment, better yet so that it reflect s the future vision for your organization. This sort of information should be captured in your enterprise architecture, in current state and future state models respectively. One goal for agile enterprise architects is to ensure that this happens in an effective manner, to ensure that the needs of the business stakeholders are understood and anticipated, and to support project teams in their development efforts.
Why are enterprise issues an important aspect of the Agile Data (AD) method? Because data is an enterprise asset. It isn’t your only enterprise asset, but it is an important one. My philosophy is that to be effective as a developer you must consider enterprise issues, which is why Agile Data’s 2nd philosophy “development teams must consider and act appropriately regarding enterprise issues” exists. However, to remain agile your organization must find a way to streamline their enterprise activities to support agile software development teams in this endeavor. Hence Agile Data’s 3rd philosophy “Enterprise groups exist to nurture enterprise assets and to support other groups, such as development teams, within your organization. These enterprise groups should act in an agile manner that reflects the expectations of their customers and the ways in which their customers work.
– See more at: http://agiledata.org/essays/enterpriseArchitecture.html#sthash.XD3SnyfY.dpuf