Stephen Cohen's thoughts on Enterprise Architecture

Capital Architect Regional Conference 2007

stephen cohen — Tue, 11 Sep 2007 06:47:25 GMT

When: October 8-9th

Where: Omni Shoreham Hotel, Washington DC

Registration link: Register online here

Description of the Conference:

The response to the Washington DC ITARC has been amazing. Attendance is way up thanks to many organizations sending their entire teams.

Refer a Friend and Win A Zune!

Send out the email to a colleague or a friend. Have them put your name in the Referred By box when signing up.

Whoever gets the most wins!

Please take this opportunity to help us really blow the doors off of our first Washington DC conference. All you have to do to support your chapter is send out this flyer and attend the event.

2 day, 4 track event for 75% cheaper than any similar event
Revenue goes to support local services in Washington DC
Developed and run by Washington DC architects for Washington DC architects
Great turnout this year = a bigger and better event next year at the same low price
Discount code for friends and co-workers for 10% off: partner436

The conference only holds 300 so get registered today.

ITARC 2007 Agenda - The following lists the sessions available at the event. Attendees will be able to get a DVD with ALL sessions from all three ITARC locations (over 100 sessions). Check out a few of the events awesome lineup of speakers

Key Notes:
- Keynote: Where We Go From Here -- The Future of EA in Government
  Richard Burk, Chair Chief Architects Council, Chief Architect, OMB
- Keynote: How to be a Successful IT Architect, Angela Yochem, IASA Fellow, SVP, Strategic Architecture Management Executive, Bank of America
- Keynote: Large Scale Infrastructure Architecture - the MSN Challenge, Michael Manos , Chief Infrastructure Architect, Microsoft MSN
- Keynote: Models and Success
  Fred Waskiewicz, Director of Standards, OMG
Enterprise Architect Track
- SOA Maturity Models, Steve Wolf, CTO, Marriott Hotels, Int'l.
- Daniel Brookshier, NoMagic
- Success in Enterprise Architecture through Collaboration, Craig S. Connell UniStar Nuclear
- Models and Governance in the Enterprise ,Mark Foster, PM Customer Deployments, Troux
- Service-Oriented Enterprise Architecture ,Yan Zhao, Director of Enterprise Architecture, CGI Federal
Infrastructure Architect Track
- Building an Effective Application Security Practice on a Shoestring Budget ,John Viega, McAfee
- Securing Wireless Access for Vehicular Environments(WAVE),Timothy Weil, Booz-Allen
- Making your systems smart (enough), James Taylor, Fair Isaac
- Infrastructure Architecture in the Business Domain,Chris Haddad, VP of Architecture, Burton Group
Software Architect Track
- Perspective Based Architecture (The PBA Method), Lewis Curtis, Microsoft Corp
- Model-Driven Agile Development, Steve Andrews, Fountainhead Solutions, LLC
- SOA is Rubbish, Steve Craggs
- Designing a Standard for Data Access in an SOA Environment, John Goodson, DataDirect
Fundamentals Track
- Agile Architecture, Jon Kern
- Architecture Analysis Methods, Denise Cook, IBM Rational
- Applying Performance Engineering principles throughout the SOA Lifecycle, Rich Larrabee
- 'Gray Matter' - Facilitating Between Technology and Business, Ron Hulen

Click here to take a look at the full agenda.

Registration

Register before September 10, 2007 to receive a $100 discount. IASA members receive an additional discount in addition to the early bird special:

Register by September 10, 2007

IASA member
Non-member

$350

$500

Register after September 10, 2007

IASA member
Non-member

$450

$600

Click here to register online

Click here to register by check or all 512-615-7900

Questions or comments? Please contact events@IASAhome.org.

Making Enterprise Architecture real step 8: Refining the Model

stephen cohen — Mon, 21 May 2007 06:39:32 GMT

In the last step we decided that a combination of federation and centralization will suit the enterprise best. So the underlying question is; what parts are centralized and what parts are federated? The answer is ... it depends! There are a variety of factors that go into the choosing. Lets go over a few of the big ones. Remember, we don't need to 100% right, just close enough to engage the rest of the team in the conversation.

Question: How tightly or loosely coupled should the parts be?

Coupling is a subject tossed about at all levels. Components, applications, services, and architectures all debate when some is ok, more is better and too much is, well, too much. I do believe the consensus is to limit tight coupling within the architecture to allow for future changes in the enterprise. There are any number of good patterns to accomplish this. Edge services and providers comprised of Brokers, Plugs, and Adapters to monitor and react to the current state of things, some variant of Bus can provide an architectural channel separating participating parts as well as creating a mechanism for implementing canonical semantics, or simple facades could be used to present and transform on a boundary.

For Message2You, the choices are driven by the current environment. Organization defines architecture. As a small company Message2You is setup as a light weight hierarchy. Cxo level managers have regional manager as direct reports. This is important. The architecture for an enterprise organized round business units tends to be strongly centralized with each business unit using most if not all shared corporate capabilities. Enterprises that are organized around geographies tend to be largely self supporting in each region and only lightly touching the corporate core. Here is an example of an enterprise that supports business units with shared corporate resources;

compare that to a more regionalized enterprise;

This second view looks like a good place to start.

The enterprise architecture has three major components areas to refine;

Shared services such as Security, logging, and Client update or patching are technical in nature and centrally controlled. Nothing but chaos comes from allowing each region to dictate is own version of these services. Next we have
centrally provided services such as Directory, Service Discovery, Broad resource management (hire/fire etc...), Broad Budgeting and Finance. These differ from the shared services in the way they are implemented. Shared services are created centrally and implemented in each region as well as the core while centrally provided services are created and reside in the core with regions implementing a mix of client access and region extensions. Last are
regionally specific services. These are unique to the region implementing them. They may or may not have any interaction with the core. Examples of regional services might be local payroll or workflow and rules engines.

Next step: Select specific implementation architectures for each interation within the enterprise.

Making Enterprise Architecture Real Step 7: First Pass Modeling

stephen cohen — Mon, 14 May 2007 05:22:00 GMT

During the last step we began scratching the surface of the needs of the enterprise. Clearly it was too broad a description to make any significant architectural decisions. Agile practices provide us a simple and effective approach to address this... "involving the customer". As we begin assembling the architecture we need to repeatedly, on might even say incrementally, engage the many representative communities the architecture is intended to support. But how best to do this? How do we create something light-weight and easily consumable by application users, Project leads, IT managers, and CO's? Personally I am a fan of the "Boxes and Lines" model so lets run with that for now.

For a macro level architecture a "Boxes and Lines" presentation might look something like this;

When we use Peer to Peer and the intent is to make every participant equal. Or maybe this;

a Centralized approach where all the participants share a single core but don't interact with each other. Another alternative might look like this;

A federation of participants comprised of mixed communication networks. Most participants work autonomously but choose one or more relationships within the federation.

Lets look at each and how well it does or doesn't support the enterprise. In our fictional organization, Message2You we have a few guiding comments to consider;

Organizations can enroll individual or groups of users Users as well as create non-user specific roles to receive messages.
Messages are validated, distributed, and secured against customer supplied rules.
Organization admin's can receive near real time status on individual messages and "correct" messages that fail to make their way through the rules gates.

To this lets add a few more things learned during our on-going conversation with individuals throughout the enterprise;

Changes made to a customer supplied rule need to effect every message immediately.
Some messages must be processed ahead of all others,
Some user organizations may not use a standard directory for their addresses, and last
Message2You wants to buy more than they build. Currently they have most of the Microsoft platform; Exchange, SQL, Office, etc...

So, are we looking at a Peer to Peer, Federated, or Centralized Architecture for Message2You?

Peer to Peer is a contender but isn't a great fit for an implementation that needs to propagate changes quickly to all points. It would however be a good choice for a highly reliable system and spreading the processing load may also prove and excellent way to scale without negatively impacting user perceived performance.

Centralized looks great on the surface. Most of the control, monitoring, and performance issues are quickly settled in a centralized system. It presents fewer moving parts and limited deployment issues. Centralization fails to support multiple independent customer organizations.

Federated addresses the multiple customer organizations by allowing each participant solution to work as independently or as connected as it might but fails terribly on rapid dissemination of change as well as it's increased management and monitoring complexities.

If none of the macro architectures work what do we do? Well there are two possibilities; first we can address the requirements and scope. It ay be possible to negotiate with our customer and re-define success in such a way that it will better fit one of the macro architecture patterns. Second we can look at combining the macro architectures and into a more problem specific composite architecture.

I'm lean strongly toward the composite architecture. One that provides the autonomous support of the federated architecture with the ease of management and responsiveness of a centralized architecture. I do not see the need for a peer to peer implementation with the requirements as we know them, but that may well change as we discover more. For now lets use this as a starting point;

This approach is centralized in that all the participating organization are required to use a centralized "core" to interact with any other organization while it has traits of federated allowing each participating organization to operate with some degree of autonomy.

It's still not enough to engage the customer in discussion. For that we need to go down another level of detail and really begin to make it address the specific issue of the Message2You enterprise.

Next step: Further refining the architecture

Making Enterprise Architecture Real Step 6: An Agile cut on the Architectural components

stephen cohen — Sat, 12 May 2007 03:39:00 GMT

Now that we have gathered some initial information we need to sort it out. Actually its more complicated than just sorting, we need to find the patterns in what we have as well as see the missing parts for what they should be. Here's how I do it;

First I grab a deck or three of blank 3x5 cards. I like the cards so I can write in any direction and draw ... well doodle really ... pictures of things. Most cards get titles reflecting some kind of logical architectural component. A few of the more common titles include; Security, Notification, External Interface, etc... I read through everything start to finish. Speed learning is part of the job. Whenever I find something interesting I note the source, the page, and the item on a card. Sources can be PPT "milestones for Foo project, Sept-04" or conversation with Bob 4-Jan.

The idea is to capture all of the high level concepts like "message based" and low level items like "Current systems prefer UDP" and general items such as "No HelpDesk" on separate cards. It quickly becomes a memory game. Every time I find something new it is either added to an existing card or gets a fresh blank one.

Early on I might create a card for federated architecture. Later when I note disconnected user it helps to put the two together. Coming across the need for "Instantaneous world-wide changes to security" will, contrary to the prior two, create a centralized architecture pile. This is just the first pass so orthogonal requirements are allowed. Once I feel like I have made a good run through everything I shuffle the deck and re-sort the piles. Sometimes they end up exactly as they were but more frequently than not I end up with a new organization.

Lets look at a fictional organization, Message2You.

Message2You provides a rule based message handling system that integrates with Microsoft Outlook and Microsoft Exchange. Organizations can enroll individual or groups of users Users as well as create non-user specific roles to receive messages. Messages are validated, distributed, and secured against customer supplied rules. Organization admins can receive near real time status on individual messages and "correct" messages that fail to make their way through the rules gates. A quick pass on the cards might look like this (please forgive my handwriting, spelling, shorthand...);

These cards group the message processing items

Here are the client side update and External Interface (EI) cards

Workflow and Notification

and last but not least, Disaster Recovery, Security, Patch Management, etc ...

In the next step we will turn this into a rough logical model

Making Enterprise Architecture real; Step 5 treasures from our information safari

stephen cohen — Wed, 24 Nov 2004 20:35:00 GMT

Back from our information safari, its time to munge (that’s a technical term) through the end-users naratives(stories), legacy systems information (relics), and our own notes (journals) collected along the way in hopes of piecing the truth together. Not just any truth, no we need to find a version of the truth that is both universally acceptable across the enterprise and internally consistent. No one item is likely to be complete. Most represent a single instance of a small portion of the broad enterprise. Taken together we still won’t have a complete picture. We can however knit together the parts that fit, extrapolate a few more, and apply our best estimate as to what might fill in the remaining empty spaces.

Let’s do a little walk-thru of the spoils.

The largest collection may well be user stories. I love these. I have yet to meet an environment where everyone from upper management to line worker wasn’t delighted to tell stories about what they do every day. I am careful to refer to these as stories. Poetic license is expected and encouraged. We need to get the flavor of the activities, the politics, and the priorities, along with the tasks and their steps. Everything, from the monthly birthday parties to the distribution of paychecks conveys something worth getting into. If nothing else, there is also a tremendous amount of good will gained by simply giving your time and listening to others. Earn it now, you will need it later. These stories can be characterized as incomplete static and dynamic views with easily attributable sources.

Next we have the relics. When discussing the day to day goings on in an organization people tend to refer to things; phone books, manuals, memos, etc … when ever possible I ask for a access to or a copy of “it”. The good news is placed in the context provided by the source, there is a tremendous amount of information in relics. The bad news is that you are duty bound to read everything you get. It is insulting to your source to get a relic only to bury it without review … read often, read fast, take good notes. Relics frequently provide static views and doctrine. There are definitive but may well be widely ignored in the real world. It’s up to you to decide which is right.

Journals are tricky. These are your notes. Mine tend toward seemingly endless pages of nearly illegible scratching. Partial sentences interspersed with the odd doodle. Sometimes there are drawings made by the person I’m talking to in a generally futile effort to get me to understand the relationship of process A to process D. Or was that a B? The point is, you need to review, edit, and generally translate your notes often. Daily works for me. If too much time passes you will likely loose some of the original fidelity. I like to capture quotes when possible but I find a lot of my notes are really odd abuses of the Unified Modeling Language (UML).

Now were getting to the real meat of the effort … Next step, Decomposition and Analysis

Making Enterprise Architecture real; Step 4 Seeking domain understanding

stephen cohen — Tue, 23 Nov 2004 05:41:00 GMT

In Step 3, I touched on how legacy choices might significantly impact the design of enterprise components. Now we need to incorporate the broader needs of the business into our design which will likely reverse some of the simplifications applied in the last step. Establishing a sound basis for changing our simplified design is as much mandate as requirement. We need to make our decisions with reasonably comprehensive knowledge of the entire business domain. Of course achieving this requires balancing our need o conduct research and analysis with the limited time to do so before the domain changes again. With fresh eyes we need to discover (or rediscover) the enterprise. We need to venture forth, leaving our cubicle, going beyond the comforting borders of the IT department, and mingle with the business in action Questioning everything and assuming nothing.

When gathering information about the domain you should;

Leave the laptop behind; I, like many, can type faster than I can write with a pen. Non-the-less, I abandon the laptop for a pad of paper when I am researching an enterprise. The laptop has a way of coming between me and those I speak with. The clicking of the keys always breaks the otherwise natural rhythm of conversation and keeping eye contact becomes, at best, difficult. I would like to believe a slate or tablet pc is a middle ground but I haven’t had the privilege yet.
Use Interview not Interrogation techniques; There are few populations as affected by television as software developers. The vast majority of developers turned business analyst I have worked with seem to have taken their interviewing style from police dramas or investigative news shows. You should avoid direct positive confrontations. Instead of saying “don’t you usually look to minimize over burdening people in the schedule?” consider, “ are all people scheduled the same way? if so how do you manage to balance things, if not what differs one person from another?” Avoid developing a theme for the people your speaking with, instead look for themes they present to you.
Avoid System terms; as users of tour echnology become more and more comfortable with how technology works they tend to translate their thoughts into our language. They mean well but don’t let them. Finding out that someone clicks a button and updates a record in the database simply doesn’t help us at this point. We need to know why they are acting on the entity or thing whose attributes are persisted in the database. What are they trying to accomplish?
Lead gently and Listen intently; we need to provoke thoughtful consideration of the business tasks and how context, workflow, and constraints affect them. This is verbal geometry. Our theorems require proofs. If someone says they receive some information to process, ask where it comes from, does it always come from the same source, is it always the same format? Find the pattern in content, schedule, etc ...

It has been said that all arguments are good. You either prove you are right or you are proven wrong and provided the opportunity to correct your own misunderstanding. While we should striver to avoid the negative aspects of arguing, we must challenge our customer and ourselves. As architects we bring technical understanding to the resolution of business issues as often as we bring business understanding as guidance to the technical solutions. Constantly seeking to define the implicit activities of the domain in explicit terms so that we may validate their accuracy and completeness helps us map our understanding of the domain and identify it’s impact on how and where we apply technology.

Making Enterprise Architecture real; Step 3 selecting abstract & domain components

stephen cohen — Mon, 15 Nov 2004 03:53:00 GMT

Selecting the right mix of abstract and domain components is crucial to achieving an appropriate balance between investment and return. Many a project has fallen into the tar pits of extreme analysis and overly complex inheritance hierarchies. It may seem academically correct to root all entities in a few abstract base class such as item and person. After all, what isn’t an item? Documents, supplies, parking spaces, are all items in their own way. The danger is in the details. Consider a single students class schedule. To fill a grid with a single semester’s information we might need to create instances of person, student, faculty, location, facility, time, calendar, item, document, and schedule.

Seems a bit heavy handed.

So what is a viable alternative? As with so many things related to design, it depends. It depends on the limitations and capabilities inherent in the technology you chose to implement your solution. It must pay homage to any known constraints of the deployed environment, as well as work with the skill sets of the staff.

For this example;

I am using Microsoft products,
I have a capable but less than robust network,
I will be serving a few thousand users who are spread out over several hundreds square miles but at least they are all in one time zone,
Security is important but not mission critical within a user type (if one member of the faculty sees another’s schedule … no problem. However a student should never see another student’s or any faculty information.)
Management wants to conduct “what if” analysis of the course schedules and related faculty assignments,
The team in predominantly mid level coders with a mix of Java, .Net, SQL server, and Oracle backgrounds, but has one very strong .Net developer as its lead.

The immediate effects these constraints imply include;

Being more stateless than not,
Using OS based groups and roles,
A high likelihood of implementing data level replication so that a given population is as close to their data as possible,
Possibly creating a separate reporting facility for management, and
Using a real database to perform fast aggregation activities.

I would consider a significantly simplified design, more like this;

Schedule is arguably a core element in the domain. It interacts with nearly all of the other elements in the domain. It is certainly worthy of the creation of a simple callable façade. The heavy lifting, the aggregation of the various components of the schedule are delegated to the database engine via a stored procedure. This allows use to implement security, pooling, partitioning, and replication. At the heart of the action is the need to find the union of the various datasets. The database already has the current values used to calculate a result. Our tool, in this case SQL Server is a highly performant, scalable set theory processor. In addition to meeting the needs of the environment, it limits network consumption by avoiding the various inter-object calls and their calls to the database for state information on construction.

Additional entities would be added AS NEEDED. Architect for the largest possible known solution but build the smallest, simplest solution possible.

So what is the right mix of abstract and domain components for your enterprise? Here are my top three questions to ask your self;

1) What applications exist today (real and imagined) and how do they overlap? In some circles this is called the enterprise portfolio. Assuming you are not looking to do enterprise re-engineering, you need to create a map of the users and their tasks across the entirety of the business. No other exercise will give you the breadth and depth of understanding needed to identify the core entities and services suitable for promotion to Domain component.

2) What is the direction of the business and what might change? It would be a best unfortunate to establish domain components representing aspects of the business about to be sold abandoned, and negligent to fail to account for a portion of the business slated to be acquired.

3) What, in real numbers, are the capabilities and weaknesses of your IT infrastructure? Enterprise solutions require communication and in our case that means networks. If they are ineffective or missing entirely you might want to push enterprise architecture off for a while. If they are in some areas than others, you have an opportunity to work with the IT infrastructure teams both identifying the issues and [balancing the usage or their prized assets.

Making Enterprise Architecture real; Step 2 separating domain from plumbing components

stephen cohen — Sun, 07 Nov 2004 20:05:00 GMT

Enterprise architects are responsible for providing simple, effective, enterprise worthy, domain components to the application developers. So what makes a good domain component?

It must provide quantifiable BUSINESS value over time. This may be the result of lowering the time and related cost required to build applications implementing the component. It may be the result of reduced helpdesk costs by standardizing error messages. It may even be the result of improved utilization across development teams by reducing the learning curve associated with each application startup. Regardless of exactly how the value is achieved it must be clear how the business will be impacted and what changes to process are required BEFORE you build it.
It must be broadly applicable across applications in the enterprise portfolio. In most organizations broadly could be interpreted to mean as few as 3 or as many as all applications. Broadly applicable components tend to make themselves available as directly callable, inheritable, or implement-able classes.
It must be stable, or at least built in such a way as to prevent future changes from damaging the applications that depend on it. Tool selection has a tremendous impact on this one. Using .Net, we can leverage things like side-by-side deployment, interface classes, and loosely-coupled events. Each component design needs to meet the minimum requirements for an enterprise worthy component.

Compare that to what makes a good plumbing component;

Provides system level services (logging, transaction management, etc…) to any calling component
Capable of providing their services in more than one business domain with little or no modification,
Don’t affect the facts being acted upon by domain components. This is an odd but consistent pattern. Data access components don’t impact the transaction they enable it. Logging components write what is passed to them without change.

As an industry we are just starting to create plumbing components for broad consumption. Microsoft’s Patterns and Practices site (http://www.microsoft.com/resources/practices/code.mspx) has several well thought out plumbing components. These are perfect fodder to kick-start the lowest level of enterprise development. Personally, I have great hope that we, as an industry, will begin to implement the plumbing behind a higher level of abstraction targeting specific Domains. Consider a school system. One would think an enterprise approach would provide components for Students, Faculty, classes, facilities, and schedules. We could logically extend this to create a layer between the domain components and the plumbing which might include, time, location, person, and organization, with a structure something like the illustration below.

Application developers could use these domain parts, without knowledge of or any need to muck with the underlying plumbing. They need only add some application specific parts, stir in the needed logic, and test well at 400 degrees for 30 minutes … and poof, one enterprise compliant application.

I don’t mean to over simplify a truly complex task. Creating an API is high art. Extending that API to object models makes it staggeringly complex for those who create them. However, this is our mountain to climb. This is the hard work that we as enterprise developers need to suffer so that all (enterprise, developers, customers, and end-users) may have their cake … robust enterprise class products… and eat it too … quick, less expensive, less complex application development.

Making Enterprise Architecture real ; Step 1- who owns what

stephen cohen — Wed, 03 Nov 2004 06:17:00 GMT

Application development code is too focused and too volatile to be promoted across the enterprise, and enterprise code is too generic and too hard to change for it to precisely address application needs. Coming to an agreement on these ownership / boundaries within the enterprise is critical for the intertwined success of all parties involved.

As a first step, I am proposing a simple ownership scheme. Given the four major types of binaries (user, application, domain, plumbing) along the X axis and application and enterprise developers along they Y axis. We can plot two curves reflecting who the "level of influence" assignable to either the developers or the enterprise. (see figure below)

The separation is not artificial, and reflects three very important principles;

The enterprise can not shift the responsibility for the creation of enterprise parts to the application developers
The Application needs can not drive the components developed for the domain or their supporting plumbing
The enterprise should not do anything which drives the way an application addresses specific application needs or the presentation related to the same.

Next, we will look at implementing the parts within the control of the Enterprise Architecture.

Can an application really be simple AND comply with an Enterprise Architecture?

stephen cohen — Mon, 01 Nov 2004 20:39:00 GMT

High quality applications are simple. They do some one thing well. The classic example is the famous Hello World app. It simple displays the text back to the caller. While there are vast language dependant permutations lets follow our own advice, keep it simple, and stick with C#.

using System;

class HelloWorldApp

{

public static void Main()

{

Console.WriteLine("Hello, world!");

}

Simple, Easy, effective … what more could one want? How about making this enterprise ready.

First we need to get more serious about what Enterprise Ready means. On the short list, and enterprise ready application would;

Comply with the enterprise architecture

N-tier
Component based

Use existing components for common tasks

Data access
Logging
Rules

Be extensible over time

Implements the façade pattern
Separates GUI from business implementation from data access

Be flexible once deployed

Provides variables outside of the compiled code

Support multiple languages

Unicode

Be secure

No trust at machine (maybe even component) boundaries
Communications are not in clear text and keys, if used, are securely stored

Left to fend for itself, this is nearly punitive overhead for a simple application. To keep it simple and meet the enterprise needs the people responsible for the enterprise architecture need to provide the parts and examples on their application (not their internals) to the developers. If the enterprise parts exists the changes to the code may be a few extra parts and a few additional lines of code.

A client windows application will need to be built to call a server hosted façade.

The façade would implant the enterprise security and call a refactored, generic text handler. Except for the text handlers overloaded interfaces, it need only know about the enterprise data access component. Every thing else would be invisible to the developer.

By most estimates the application would still be considered simple;

Windows form code;

private void button1_Click(object sender, System.EventArgs e)

{

myFacade myF = new myFacade();

CultureInfo cu = new CultureInfo( "es-ES", false );

string s = myF.getText(text, cu);

this.textBox1.Text = s;

}

Façade code;

using System;

using System.Globalization.CultureInfo;

namespace MyCompany

{

public class getText

{

public string getText(string text, CultureInfo cu)

{

string s = MyCompany.Dattacess.getCutlureText(text, cu);

return s;

}

Complexity for the enterprise is provided by the enterprise;

The text handler would get text from a database or resource file using an existing data access component, and ensure the connections a managed and the correct language is returned in the appropriate character set.
Access controls would have been established and implemented in groups and roles
Logging would happen by attributing the appropriate interfaces in the data access class.
The users identity would be flipped to a generic application role which would limit access and improve performance.

So a simple application can comply with the enterprise architecture but ONLY IF the enterprise invests in providing the application developers enterprise ready components BEFORE the application is being built.