Enterprise Architecture: Different Views: August, 2008 archives

Enterprise Architecture: Different Views:

August, 2008

Aug 31 2008   7:40PM GMT

EIA within EA Context



Posted by: Anton Venter
Enterprise architecture

Here’s another interesting view by Gartner of how Information Architecture fits within the context of Enterprise Architecture. In the accompanying diagram (which depicts EA) the shaded area in column 2 shows the scope of Information Architecture. Note how the word “business” features in this diagram - especially where the application architecture is concerned.
In my September blogs I will present examples of practical implementations of the frameworks we theorised about. No use in wallowing in theory for too long - practical application is what it’s all about!
EIA in EA Contect

Aug 25 2008   11:57AM GMT

The ROI of EA



Posted by: Anton Venter
Enterprise architecture

Why is it worth practising EA and what is the Return on Investment? One could argue that the ROI all comes from Information and its use, so it could be a Return on Information. Firstly, if the architecture (current) is documented, it is easier for people to find information. For example, if an audit is required of all application software, the information will be readily available. In my (large) organisation the Application Architecture is reasonably well documented and it was easy to provide our new outsourcer the information to support our applications. Secondly, if the organisation wants to promote re-use of processes, applications, data and infrastructure items, it needs to have these inventorised with views that can be understood by business as well as IT development staff.


Aug 25 2008   11:56AM GMT

Major EA Frameworks



Posted by: Anton Venter
Enterprise architecture

I previously discussed EA Frameworks and some readers might be wondering about the terms “framework”, “process” and “methodology” and possible overlaps between these. Looking more closely, the Zachman Framework is very useful to apply a taxonomy when describing a current or future EA. The TOGAF is very useful when deciding on an EA Process or Method (remember the Architecture Development Method within TOGAF?). Lastly Gartner offers their EA Methodology - useful when looking for a Method to use for the Practising of EA. So these are different concepts, but should be combined in an EA effort to increase the chances of success.


Aug 20 2008   5:05PM GMT

TOGAF’s ADM



Posted by: Anton Venter
Enterprise architecture

TOGAF’s ADM consists of the following stages:
- Preliminary phase (deciding the framework to be used and principles, getting commitment, planning)
- Architecture Development (vision, Business architecture, Systems architecture, Technology architecture)
- Business Transformation planning (solution opportunities and options, migration planning)
- Architecture Deployment (governing the implementation)
- Architecture Realisation (managing change)


Aug 20 2008   5:03PM GMT

TOGAF



Posted by: Anton Venter
Enterprise architecture

Ever heard of TOGAF? TOGAF is The Open Group Architecture Forum with which architects can become a member and get certified as an enterprise architect. TOGAF subscribes to a number of EA Frameworks, but also offers an ADM - Architecture Development Method(ology). I have found the ADM a very useful and structured way of approaching EA, whether it’s just a single new solution or a complete EA programme that is required.


Aug 20 2008   5:02PM GMT

EA Components



Posted by: Anton Venter
Enterprise architecture

The components of an EA can also be summarised as follows:
- Context (basic requirements, guidelines, constraints)
- Framework(s) that enable a multi-layered EA development in stages
- Actual components (processes, systems, rules)
- Inter-relationships (links, flows, data dictionaries, database indices)
- Models
- Architects


Aug 16 2008   10:12AM GMT

Outputs of EA



Posted by: Anton Venter
Enterprise architecture

What are the typical outputs of Enterprise Architecture?
Views and models that describe the “current environment”, based on one of the EA frameworks already discussed. This is required to enable a grasp of the gap that exists considering the desired future environment (another output of EA, also described with models and perhaps the same framework). The next set of outputs - design guidelines and patterns - are used in the activities to govern IT work along the most efficient and shortest path towards the future environment.


Aug 16 2008   10:11AM GMT

EA Programme Roles



Posted by: Anton Venter
Enterprise architecture

I briefly discussed before how EA teams are typically structured, but what are some of the other roles on an EA Programme? Apart from the specific domain architects, e.g. Application, Information and Security architects, other important roles to be considered are the Architecture Sponsor (could be from within the business), any other Architecture Board members required to ensure the success of an EA programme, and - don’t forget - project/programme members, solution designers and developers. Any EA programme will not succeed if there is no buy-in from the IT Development community, especially an understanding of how and why EA governance plays a role in Solution Development.


Aug 16 2008   10:09AM GMT

EA Critical Success Factors



Posted by: Anton Venter
Enterprise architecture

What are some of the key Critical Success Factors of Enterprise Architecture?
Primary CSFs:
- Planning the EA programme
- Developing an Infrastructure for EA (tools, frameworks, methodologies)
- Documenting the EA - current and future
- Standardisation of Design Patterns, Development Processes and Application Architectures
Secondary CSFs:
- Architecture Governance in place and working
- Stakeholder participation


Aug 11 2008   6:57PM GMT

What about SOA?



Posted by: Anton Venter
Enterprise architecture

Is SOA the same as Enterprise Architecture?
No - SOA is rather an Architecture STYLE. If BSOA is seen as the Business View of SOA, then EA = SOA + BSOA. SOA is a useful vehicle to apply re-use of solution components and govern design of components according to design patterns.