Enterprise architecture is typically used to describe an agency - wide or organization - wide framework for portraying and incorporating the business processes, information flows, systems, applications, data, and infrastructure to effectively and efficiently support the organization ’ s needs. At the heart of this definition lies a very broad context aimed at including many different portions of an organization ’ s participating branches, chief among them the business and information technology departments. We could wax intellectual all day long on the merits of these descriptions, but seeing as how this is a book for developers, let ’ s cut to the chase. What does enterprise architecture mean from a developer ’ s point of view? It means defining a process, framework, and set of patterns to design, develop, build, and maintain all of the software that an agency or company needs to operate. The operative phrase here is all of the software . It is a unified development platform for creating all elements of software at all levels of design. It includes reusable tools for building client applications, websites, databases, office applications, business automation tools, scripts, and just about anything else that a company may use to get things done. Enterprise architecture also endeavors to break down each of an application ’ s layers into modular pieces for reusability. These reusable elements can then be used to feed or drive other applications with similar needs. Here ’ s where the picture starts to get a bit fuzzy. Most developers take on projects with a finite set of business goals, goals that satisfy a specific need or company requirement. Within that scope, there is little consideration for modularity or reusability outside of the system that is being built. On the contrary, project goals rarely allot the time and resources needed to accommodate what is in essence the possibility of component reuse. Instead, typical projects focus development on the end goal only, marginalizing or downright ignoring the larger enterprise picture. Understanding enterprise development means first realizing that this kind of myopic, and often cavalier, development is ultimately counterproductive.
Enterprise architecture is also about defining a solid foundation of code and practices that eventually (and inevitably) facilitate interoperability in a heterogeneous software environment. This foundation provides both a toolset for creating software application, as well as a set of boundaries and rules within which those writings said applications need to work. The combination of both process and toolset is one of the key concepts to creating enterprise software. It expands on the otherwise traditional concepts of computer programming that concentrated on what one coded and mostly ignored how one coded. The incorporation of software development methodologies and lifecycle management becomes as important a part of building an application as the code itself.
Of course, chances are that if you ’ re reading this book, you ’ ve already come to know some sort of development methodology. From the iterative and flexible like Agile and Extreme Programming, to the evolving and maturing like Six Sigma and the Capability Maturity Model, software development methodologies have worked their way into mainstream software development. Still, methodologies alone do not define an enterprise architecture. Plenty of shops that build applications apply these methodologies rigidly, and many of them do not have enterprise software. An organization that embraces enterprise architecture endeavors to combine a broad - context framework with a development approach, ultimately yielding code that conforms to a level of quality and design that suits the organization ’ s core needs. Ideally, this approach can do wonders for a company, ensuring quality and uniformity throughout all tiers of design. Yet anyone who ’ s participated or contributed to more than one enterprise shop would agree that the ideal is difficult to attain. Business needs and company politics often work counter to the spirit of enterprise planning. They force stringent timelines and tight project budgets, and don ’ t easily allow for the sort of flexibility that a good enterprise architecture requires. The result is a hackneyed combination of some processes and standards that add little more than cumbersome meetings and a few tidy lifecycle diagrams that barely placate the folks in charge. Thus, a successful implementation of an enterprise system requires a comprehensive “ buy - in ” from both members of the business side and from the IT side.
Source of Information : Wrox Professional Enterprise dot NET
Enterprise architecture is also about defining a solid foundation of code and practices that eventually (and inevitably) facilitate interoperability in a heterogeneous software environment. This foundation provides both a toolset for creating software application, as well as a set of boundaries and rules within which those writings said applications need to work. The combination of both process and toolset is one of the key concepts to creating enterprise software. It expands on the otherwise traditional concepts of computer programming that concentrated on what one coded and mostly ignored how one coded. The incorporation of software development methodologies and lifecycle management becomes as important a part of building an application as the code itself.
Of course, chances are that if you ’ re reading this book, you ’ ve already come to know some sort of development methodology. From the iterative and flexible like Agile and Extreme Programming, to the evolving and maturing like Six Sigma and the Capability Maturity Model, software development methodologies have worked their way into mainstream software development. Still, methodologies alone do not define an enterprise architecture. Plenty of shops that build applications apply these methodologies rigidly, and many of them do not have enterprise software. An organization that embraces enterprise architecture endeavors to combine a broad - context framework with a development approach, ultimately yielding code that conforms to a level of quality and design that suits the organization ’ s core needs. Ideally, this approach can do wonders for a company, ensuring quality and uniformity throughout all tiers of design. Yet anyone who ’ s participated or contributed to more than one enterprise shop would agree that the ideal is difficult to attain. Business needs and company politics often work counter to the spirit of enterprise planning. They force stringent timelines and tight project budgets, and don ’ t easily allow for the sort of flexibility that a good enterprise architecture requires. The result is a hackneyed combination of some processes and standards that add little more than cumbersome meetings and a few tidy lifecycle diagrams that barely placate the folks in charge. Thus, a successful implementation of an enterprise system requires a comprehensive “ buy - in ” from both members of the business side and from the IT side.
Source of Information : Wrox Professional Enterprise dot NET
|
|
0 comments
Post a Comment