Tuesday, February 21, 2006
EA and Reference Architectures...
An architecture can exist at many levels. Minimally, at the conceptual and physical levels with lots of stuff in between these two perspectives. The key belief is that architecture in of itself is not really physical. Architecture is an abstract concept (sometimes the folks responsible for creating it are more abstract that the architecture itself but that is a topic for another blog) that encompasses many categories of principles. Architecture is the art, science, method, and style of building something that fulfills the practical and expressive requirements of a group of humans.
Individuals or groups create architectures to fulfill their specifications. Users, who set the goals, establish different types of architecture, not the architects. Architectures tend to be stable, and to change an architecture, a need must exist that exceeds economic considerations (see past blogs on software engineering economics), because repetition is less expensive than experiment (always true) and innovation (mostly true).
In an architecture, standardization of elements can be useful to achieve financial saving or, more importantly, an architectural value. A good architecture creates an attractive appearance and connotes the intended message to the beholder. The thing being built using a good architecture should not only be structurally stable but should also appear to be stable (An architecture minimally shouldn't smell).
The thing that the enterprise needs is the notion of a reference architecture that is known and developed to the extent that one enterprise can find a way to use another enterprise's architecture, for whatever reason. This begs the question of whether each and every single enterprise should create their own or should figure out how to borrow from others. Reinvention of points of reference across enterprise boundaries may serve the need to achieve buy-in but fails on economics, use of best practices and adherence to accepted forms of body of knowledge.
Reuse of reference whether accomplished by standards, by clever software design, or both, is something that must be investigated and discussed. The things we have with which to work are the enterprises, that are comprised of people, then processes then tools in that order should come with frameworks; enterprise models; suggested or required methodologies; and guidelines and rules for using each. The enterprise architecture, or enterprise-reference architecture, is the organization of all of these things.
Should reference architecture guide the following?
- Whether to outsource or maintain competitive advantage in-house
- Whether to build reference architectures internally or buy them
- Hiring practices that allow the enterprise to get the best in the industry and not just rationalize mediocrity
- Whether to embrace open source for competitive advantage and not just commoditization and cost considerations
- Steer IT executives towards notions of strong technical leadership
- Adoption of agile methods for software development
- Whether an enterprise should interact with a larger community in terms of blogging and speaking at conferences
- Modern approaches to architecture including declarative programming, event-driven architectures and Bayesian Belief Networks
- Whether to spend lots of money on commercial portal software or adopt an open source portal such as Liferay
- Whether to spend lots of money on commercial Enterprise Service Bus or adopt an open source ESB such as ServiceMix
Anyway, I would love to hear from others on their interpretation of reference architecture.
Links to this post: