What Are Enterprise Architecture and Enterprise Development?

What Is Enterprise Architecture?

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 form 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 single, 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 form of myopic, and often cavalier, kind of application 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 applications and a set of boundaries and rules within which those writings said applications need to works. 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 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.

What Is Enterprise Development?

Enterprise development commonly refers to the patterns and practices adopted by programmers endeavoring to implement enterprise architecture. It is the employment of certain approaches and methodologies that aim to achieve many of the root goals inherent to a successful enterprise system. What these goals are specifically changes from organization to organization; however, at the root, they address five key areas of system development:

1. Reliability

2. Flexibility

3. Separation of concerns

4. Reusability

5. Maintainability

These base tenets are embraced by all developers of enterprise systems, and they help to define the core of what most modern developers consider to be well-designed software. Enterprise development embraces these ideals, weaving them subtly into the tools and processes that drive software logic.


Most would agree that designing systems that are reliable is a must. Yet coding for reliability is a departure from business as usual. This is especially true in the rapid application development community. Writing code that can be well tested means changing the way that a system’s functionality is modularized. It means flattening out otherwise bloated classes and removing dependencies, or rather, removing references to other code that prevent a class or module from being tested. Many of these design patterns are integral to a process known as Test Driven Development, or TDD. We will cover TDD in depth in Chapters 3 and 4 [of the book "Professional Enterprise .NET" by Jon Arking and Scott Millett (ISBN: 978-0-470-44761-1, Wrox, 2009, Copyright Wiley Publishing Inc.)].


Requirements can change. As a result, so must the software that supports them. If the code that you write prevents an application or system from being extensible or pliable, we would say it lacks flexibility. Many people mistake the need for flexibility for other popular engineering subjects, such as interoperability or failover. However, enterprise flexibility addresses the ability of code to be broken down and shared by different systems applications. A program might be functional on different platforms, or contain logic for lots of different failure scenarios, but that wouldn’t mean it was flexible. A flexible system would allow for the changing for core features without violating unrelated services or attributes.

Separation of Concerns

Separation of concerns is simply the process of breaking a system or application down into distinct functional layers with limited overlapping of functionality. Like flexibility, separation of concerns addresses the ability to modularize code and make it more pliable, with the added benefit of logical division. Much of this division can be achieved through well-known object-oriented tenets, such as modularization an encapsulation. As we explore new fields of development, such as aspect-oriented programming (AOP) separation of concerns becomes an all-important piece of the enterprise puzzle.


Sharing features and services is tantamount to good enterprise design. As code is broken down and separated into logical pieces, these pieces should be designed to provide a distinct feature or satisfy a particular requirement of other systems that invoke it. The scope of a class’s reusability depends on the context in which it is used; however, most agree that other modular pieces of code within a similar context should always be callable. In other words, classes at any one logical level should be reusable by other classes in the same logical level. Classes that provide data should be consumable by all other classes that demand data within scope. Classes that implement a user interface (UI) behavior should deliver the same behavior to all UI-implementing classes on the same UI tier. The notion of reusability is especially important when designing true enterprise architectures.


Maintainability refers to the capacity of a system to be altered or modified. Although most software engineers think they know what maintainability means, it actually has a distinct meaning in the world of software design. According to the international standard of software development defined in ISO 9126, the term maintainability actually means the ease with which a software product can be modified in order to:

  • Correct defects

  • Meet new requirements

  • Make future maintenance easier, or

  • Cope with a changed environment

Maintainable code should be the natural result of following the other four tenets, provided that the designer has not introduced unnecessary levels of complexity. The inherent balance between complexity and maintainability will be explored further in Chapter 2.

For a great many software engineers this can be a dramatic shift in the way they program. It requires a rigid manner of programming, employing new concepts and demanding more upfront design than the typical developer usually executes. At close glance, one might think that simple, non-enterprise computer code that delivers a particular feature is identical in value to enterprise code that delivers precisely the same feature. Yet this myopic evaluation fails to address the greater needs of the system, namely core enterprise concepts. While the code may deliver similar results, the enterprise code takes strides to accommodate better design. So while the enterprise sample might look a bit more complex (only at first, mind you), the resulting class or module ultimately provides more reliability or is more maintainable.

Consider a simple example. Two developers are required to build a web page that displays dynamic feeds of financial data. These feeds can range from stock quotes to bond prices to billboard articles from popular financial journals. The non-enterprise developer might write an ASP.NET page with a set of data grids, each bound to different database calls and online web services. The bindings are created in the ASP.NET code-behind page directly, placing a good amount of data logic side by side with some of the user interface behaviors. The enterprise developer would take a slightly different tack. Using the Model-View-Presenter pattern widely embraced within the enterprise community, they define a class to garner and hold the data on its own. They then create another class to handle the user interface logic and events, defining both classes with an abstract interface that defines each of the classes’ core methods. Finally, the developer writes a series of unit tests and mock classes to test the code and ensure that all portions function as intended. Figure 1-1 shows a diagrammatic depiction of the differences between the two patterns. The resulting software delivers precisely the same page and the same data, with much more orchestration and modularity. So the two efforts were a wash, right? Let’s take this model a step further. The sample page hits its mark. Management is happy and they request that the page be published on the company website. The website requires a level of account authorization in order to query data from other data sources, but neither developer is aware of this. The non-enterprise developer deploys the web page directly and takes a quick look at it using a browser running on his/her desktop. They are logged in as an administrator, so the web page loads just fine. Unfortunately when others try to view the page they get a horrible system error that crashes the entire web session. On the other hand the enterprise developer took time to write a unit test that impersonates an anonymously authenticated user in the data access class. They run the test as a part of the build process and the problem becomes immediately apparent. The enterprise code is more reliable than the non-enterprise code. What’s more, the composition of the web page code to support the unit tests allows for modularity and separation of concerns. So when management provides a new data service to use, the data layer can be altered with minimal impact on the user interface. The code is now more flexible, too. The added flexibility, along with the reliability and logical separation, makes the enterprise developer’s web page far more maintainable than the non-enterprise developer’s page.

An enterprise architecture can be difficult to build in its entirety. Typically speaking, an individual software engineer has limited say over how a business expends its resources.

For most developers this is a game-changing approach to writing code. The vast majority of developers in the Microsoft world concentrate on developing software for a single system or application. This is completely understandable when you consider that an overwhelming number of career Microsoft developers began as business analysts or specialists who, thanks to the proliferation of rapid application development tools in the Microsoft software space, took on coding as a means of automation. Yet despite the upfront convenience of rapid application development, the cost in the long run can be, and usually is, very high. Enterprise development aims to reduce these long-term costs with prudent designs, approaches, and testability. Where Is All of the Microsoft Enterprise? 

This article is excerpted from chapter 1 "What is Enterprise Design" of the book "Professional Enterprise .NET" by Jon Arking and Scott Millett (ISBN: 978-0-470-44761-1, Wrox, 2009, Copyright Wiley Publishing Inc.)



Leave a Reply

Your email address will not be published. Required fields are marked *