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...

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...

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...

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...

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...

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...

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...

Being service oriented (SO) is, and continues to prove itself to be, a valuable and elegant approach for applications as well as enterprise architectures. However I am a bit baffled by why an architecture which is service oriented is being branded a new kind of architecture. An architecture may or may...

I am a big fan of risk management in all projects. It is however generally rare to see risks identified when developing an enterprise architecture. On the one hand, this seems to make sense. Enterprise architectures are there to address the shared risks for others. They are the cure, not the cause. Unfortunately...

I have mentioned in prior blogs my belief that an enterprise architecture is comprised of 3 intertwined components; standards, governance, and a repository of binaries. I will address standards and binaries later. For now, I will focus on the concrete manifestation of governance. ...

Most of us can agree that there is always more than one way to achieve a given piece of functionality. Consider getting a phone number for a person from a Sql database. You can connect with integrated security, or pass in the username & password, or maybe implement application roles...

A common phrase used to describe an enterprise architecture is a set of “living documents”. I like it. Short, simple, easy to understand … a living document. Of course there is a dangerously complex implication lying just below the veneer of this simple metaphor. Living implies change...

Enterprise architects are the one star generals of their business. They have some authority. Usually less than their subordinates believe they have, and more than their superiors and peers want them to have. Ultimately, it comes down to the individual architects vision and their ability to lead others...

Just as the selection of materials has a substantive impact on the form and function of a structure, the concrete choices made by an enterprise have undeniable impacts on the form and function of the enterprise architecture. Creating products without regard to the tools and material in play as well as...

So you have an enterprise architecture ... How well does it work? Here is a quick test, a mere 5 questions, intended to help evaluate it. But first a few rules; This is only applicable to DEPLOYED architectures. Generally, deployed means stable and used by at least 2 applications for at least...

Developing a broadly available set of services upon which your enterprise will rest is a daunting task. Typically difficult issues such as performance, scale, and availability need to reach 10 or 100 times that of a single application. Consider a simple logging mechanism. Implemented for enterprise consumption...

The enterprise architecture team is responsible for exposing core functionality in ways that support the application teams. But how is that best done? I would like to propose a combination of 3 approaches: * Registration al la COM+ * Enterprise components made available...

I spent the last week working on a proof of concept for a very large customer. They wanted to build a service oriented software infrastructure to be used across many well known, and all possible future, applications. The principle goal is to provide safety and security in a structured and predictable...

Step with me if you will onto the slippery slope of enterprise architecture definition. I try to capture the boundaries of the enterprise in a single simple layered boxes-and-lines diagram. Relationships are conveyed through adjacency and separation helps define inappropriate lines of communications...

Two skills have served me well while gathering information about an enterprise. First, the lessons it has been my pleasure to have learned from my customers and the many, many, bright practioners I have been lucky enough to work with. Second, the ability to forget all of those lessons and question everything...

Enterprise architecture products are decomposed into two primary categories; Inward facing products guiding or documenting the activities of the enterprise architecture program, or Outward facing products used to facilitate discovery and communicate the interim findings of the EA team. ...

How big is your enterprise? It turns out to be a very difficult question to answer. Consider this simple scenario; You have a newspaper delivery route. Your supplier pays you as a contractor. You receive the newspapers each morning from another independent contractor. Each home you deliver to is...

Many discussions of how-to-do architecture talk about modeling the domain 'as-is' then defining the 'to-be' state. In general I agree, clearly defining the problem before identifying the solution is a risk mitigation technique. By focusing on the current state you avoid artificially injecting constraints...

I believe that enterprise architecture more closely resembles social structures than physical structures and enterprise architects are more closely related to the authors of the declaration of independence than structural engineers. This is a key differentiator when discussing application vs. enterprise...

Enterprise Architects face many directions at once and the deliverables are intended to help with the various lines of communication. * The models help aid the validation and discovery phase with the stakeholders and later provide a well known visualization of the stakeholders plans the architect...