Models and Leadership in Enterprise Architecture

What matters most in enterprise architecture? Is it the business model, or the people who lead the organization? Chris Potts reviews this question in his latest post on CIO. One of the points Chris brings up relates to the Economist’s article "No Size Fits All", which explores whether the business model or the people managing it were responsible for the credit crunch.

According to Chris, replicating a business model within organizations does not guarantee success or failure. Only people, ex: customers, suppliers, partners, and employees are able to make a model work. Chris states that business instead, should start on the right hand side like the Zachman Framework for EA (Who, When, Why), not the left (What, How, Where).

Is your organization more concerned with its structure than management?

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

Adopting SOA: More than just getting the software

In a recent article at CIO, Ty Anderson discuses how adopting SOA into the business is like buying a total home gym. Buying it doesn’t get the job done, it’s important to use the purchase continually in order to get the benefits the software can offer.

-- It’s important to audit existing applications. See what the processes are for your current business processes. Know what you’ve got so you can start in the right place.

-- Make the services as simple as possible

-- Work with your SOA tools every day. You’ve got to continually work towards the adoption, day in and day out to find out how the software truly works.

-- Keep working – Now that you’ve got SOA, it’s important to keep it current. Learn what’s new in the software and implement additional tools that are beneficial to your company.

And throughout the whole process, have someone there to keep you going in the right direction. A mentor can help you achieve your goals and keep you working towards the benefits of SOA.

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

The IT and Business Divide

In this article the pIT stop panel was interviewed about the possibility of enterprise architecture in bridging a gap between the IT and business divide. Their answer was

“If I had a polo mint for every time I heard that a technology or approach would provide “alignment” between IT and the business I would walk around with permanently fresh breath.”

While they say there is no easy fix in bridging the divide, they did say that this did not negate the importance of “establishing formal ‘enterprise architecture’” They said that they have seen improvements in IT and business alignment especially in terms of SOA. One piece of advice they gave was to start small. In addition, they mentioned that instead of simply relying on technology or an approach, it is important for organizations to understand the importance of “human factors”.

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

Types of Enterprise Architecture

In a recent article at Inside Architecture, Nick Malik took time to detail the different enterprise architecture frameworks. He then goes on to pose the question, what would the ideal framework be? What would you take from each of the individual methods below to make your enterprise architecture fit your needs?

- TOGAF - Basic strength: solution architecture. Various models and how to create them. Basic weaknesses: Planning methods and governance framework. Weak on Information Architecture

- FEAF - Basic strength: complete implementation tied to measurement framework. Basic weaknesses: very specific to government, lack of independent process taxonomy keeps processes "in the silo."

- eTOM - Basic strength: excellent process taxonomy with rich details. Strong information architecture. Great for governing external vendors. Basic weaknesses: fairly specific to telecom industry, gaps in governance and enterprise architecture models.

- ITIL - Basic strength: excellent process framework for operations and (now) governance. Basic weaknesses: no architectural methodology to speak of. Sizeable gaps in information or application architecture.

- Enterprise Unified Process - Basic strength: soup-to-nuts coverage of enterprise software development processes, including funding and operations. Basic weaknesses: poor adoption rate and lack of a governing body to allow for growth, minimal architectural methods, no enterprise process or capability framework.

- Zachman - Basic strength: comprehensive taxonomy of architectural artifacts (to let you know when you are done). Basic weaknesses: Lack of published and vetted methods to avoid "boil-the-ocean" exercises and focus on one particular benefit. Very shallow: No detailed process, capability, or solution frameworks for "level 2" detail. Highly proprietary.

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

Start Small for SOA

This article brings up an interesting point that it may be best to start small when it comes to introducing SOA to an enterprise. While the initial reaction maybe to begin with projects that are high profile, oftentimes without the cooperation from the IT and business departments such projects have the potential to lead to frustration, and ultimately may make individuals feel that SOA failed. To prevent this feeling, it could be beneficial to start on smaller projects where there is plenty of cooperation in order to build “momentum”. With one successful project, it becomes easier to show the benefits in order to gain cooperation on the second, and thereby gaining trust in the usefulness of SOA for organizations.

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

The Goals of EA

Every organization defines the goals of Enterprise Architecture in their own distinct way. Anton Venter lists six goals of practicing enterprise architecture in his latest post on the IT Knowledge Exchange. Here they are:

1. Successful and timely Business transformation
2. Bringing models and views together by implementing universal compatibility between them (integrating everything and using a common language)
3. Going on-line, e.g. by using a portal
4. Maintaining a balance between strategic enterprise-wide goals and the operational and tactical needs of individual business units or segments
5. Focusing on short- and medium-term Business benefits
6. Focusing on 20% of major threats and opportunities that will have an 80% impact on the Business

What are your company’s goals of practicing EA? Do they differ from Anton’s?

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

Coordinating information company wide will help SOA

In a recent blog post by Nick Malik at Inside Architecture, he ponders a very common question: Will information in the enterprise ever be able to be coordinated? Many of his readers think it is a nearly impossible task, but Nick believes with a little bit of software and coordination, it can happen. While all information is department specific, there is some overlap that can be coordinated. The value of coordinated communication is not something businesses should look over.

Nick believes that the information can be a powerful asset if shared throughout the company. So the easiest way to do this is to come up with a submission model. This model would be assembled by enterprise architects, then put together in a common repository. They can then assemble the information together in a way that information could run parallel in departments. Nick points out that in the end, we may be closer to having enterprise-wide architecture. There will be criticisms throughout the process, but the productivity in the end will shine brightly for enterprise architecture efforts.

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/