See you at Evolve EA!

For some time now you've probably noticed our linking to a new sister blog titled Evolve EA. Our new blog will still look at the multiple disciplines that make up enterprise architecture and provide clarity to the alignment between business processes and IT infrastructure in the support of integration and standardization across the enterprise. Since we've established this corresponding blog we want to officially invite you to join us and subscribe to our feed: http://feeds.feedburner.com/EvolveEA

As you've already seen, we've been building up the Evolve EA blog with the same quality content that you find here. Beginning today, this will be our last post on this blog but you can join us on the Evolve EA blog, where we hope you'll continue to actively participate as you have here. Thank you and we look forward to seeing you at Evolve EA.

IT Professionals Might be Looking Elsewhere for Employment

James McGovern’s latest post on Enterprise Architecture discusses how many enterprise architects are favoring contract/consultant work over permanent work because of the better paying opportunities and offers.

Enterprise architecture in general might suffer is some of the more qualified IT professionals are leaving organizations for contract work. Another point that James brings up is that perhaps HR isn’t allowing for much flexibility on salary compensation for enterprise architects. Is your company currently using consultants for its enterprise architecture initiatives?

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/

Hottest IT Jobs

In a recent research study done by Forrester, discussed here at InfoWorld, they released what their analysts believe are the hottest jobs in IT. The hottest of all jobs available were information/data architects and information security experts. Making the extremely hot list was data/content oriented business analyst, business architect, enterprise architect, and vendor management experts.

Of all the jobs on the list, Forrester found that these attributes were most important characteristics in all the jobs listed:

* Local knowledge of the business industry or region.
* Cross-discipline knowledge; understanding both management practices and customer groups.
* Those willing to take on high-risk roles that, if successful, will have a major impact on the business.
* Limited external supply; that is, while an outsourcer may be willing to supply 500 coders, the benefits of finding you a half-dozen enterprise architects is not worth their while.
* Consistency with technology, vendor, or industry direction, meaning rapid changes in technology; an example is how mobile put a higher demand on real experts who have domain-specific knowledge.

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/

Growth of SOA in India

Business Standard mentioned today, in this article, that India is expected to have the “fastest growing SOA market in the Asia-Pacific region”. Springboard Research has predicted that this market will have a compound annual growth rate of 49% from 2006 to 2009. Many organizations are already starting to seize this opportunity. Intelligroup, one company interested in this growth rate, believes that 20% of the “larger SAP customer in India” will be adopting SOA within the year. Liladhar Bagad, practice head of Intelligroup, released this statement as a means to explain this growth:

“As organisations become more global, SOA will become an integral part of their strategy. It is aimed at lowering the total cost of ownership, simplifying integration and customisation. Organisations are increasingly embracing SOA as a means to access and distribute information in real time”

It is cautioned, however, that organizations need to be aware of disappointment that some companies may announce. As Chandika Mendi, director and head of Virtusa Corporation, explained

“The reason for the disappointment will be due to taking a much narrowed approach while defining SOA, which could lead to failure of implementations. Also, the initial investment in SOA is high and will reap benefits slowly as the entire enterprise moves to it, which is a fairly long journey,”

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/

Return on Investment or Return on Information?

Anton Venter’s latest post on the IT Knowledge Exchange argues that the real ROI of EA comes from information and its use. Anton makes another great point that documentation of architecture makes finding information easier and readily available. It also becomes easier to provide outsourcers info on the architecture should they need it to support an organization’s applications. What do you think is the real ROI of enterprise architecture?

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/

Putting the "E" in TOGAF: An EAdirections Webinar

In our attempt to deliver the latest updates and insights within the EA space, we’ve scheduled a series of free webinars that will happen over the next couple of months. The first webinar in the series “Putting the "E" in TOGAF: An EAdirections Webinar,” will be presented by three managing directors of EAdirections: Larry R. DeBoever, George S. Paras, and Tim Westbrock. Register now for the webinar on Thursday, Sep 4, 2008 from 2:00 PM - 3:00 PM EDT to save your webinar seat. Here’s a brief description of the webinar and what you can expect to take out of it by attending:

A number of EA practitioners have concluded that TOGAF is not an effective framework (and ADM is not an effective methodology) for Enterprise(wide) Architecture. TOGAF does not cover aligning long-term corporate strategy with IT, and positions EA as a reactive, rather than proactive, approach. In fairness, many have expressed similar concerns about other EA frameworks and methodologies. This webinar explores the “enterprise-ishness” of TOGAF. We discuss our experiences and practical techniques for extending TOGAF (and other frameworks) to significantly increase its effectiveness across the Enterprise.

If you are a Chief Architect or IT manager evaluating EA frameworks, or if you are struggling to apply TOGAF (or another framework), on an enterprise-wide basis, then this webinar is for you. Topics will include:

What you will learn:

• What are the types of enterprise-wide requirements that users of TOGAF struggle with?
• What are the enterprise-wide architectural activities that EA teams should be performing without a clear ‘Business Requirement’?
• How should an Enterprise Architecture account for the fact that most enterprises do not have an ‘end state’ but rather continually adjust to changing markets and opportunities for innovation?
• Are the artifacts produced by TOGAF effective for communicating with the Board and the Executive Committee? If not, can they be made ‘consumable’?

This webinar is being brought to you by the Enterprise Architectures Conference, don’t forget to take a look at the lineup of speakers we have this year. Click on the link below to register for the free webinar.

https://www1.gotomeeting.com/register/924415223

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/

Path to Become an Enterprise Architect

Praba Siva, in this blog post, created an excellent chart for the path that an individual should follow to become an enterprise architect. He details what type of positions you should hold, for how long, the skill sets learned from each position, as well as what the next steps and positions should be. (Click on diagram to see a larger version)

Alan Inglis, in this blog post, discusses the above chart. He comments that he would add a business entry point, and would also like to see an entry point from an “information or data perspective”.

What are your thoughts? Is there anything else you would add to build on these two authors viewpoints?

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/

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/

New technology means more responsibility

In a recent post at User Centric Enterprise Architecture, Andy Blumenthal explores the craze that has come with having access to the internet and being connected 24/7. Blumenthal spoke an official at Northwest University Hospital, and found out that he’d treated patients who’d suffered from injuries while texting at least once a day. Now that we have access to all business information at any second, people can be more productive but only when the tools are used properly. It’s important for the enterprise architects of the organizations to teach the users of their technology appropriately. It’s important to focus on the human aspects of the tools of enterprise architecture and pass them along to those using the tools.

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/

Excellence in Enterprise Architecture

In a recent post by Nick Malik, he details how he was asked a question about whether or not Microsoft provides “internal support to create an Enterprsie Architecture program.” Upon reflection, Malik felt that, yes Microsoft does support the EA team. He also remarked on his definition of what constitutes excellence:

Excellent, to me, means that the effort is tailored to the needs of the business. That includes business strategy, business structure, and corporate culture.

His opinion is that this definition of excellence is different for everyone. Do you think there is a common way to define it? And what would you define as attaining excellence for an enterprise architecture program?

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/

Carphone Warehouse sees benefits to SOA

As reported by this article at CIO, Carphone Warehouse, a mobile phone retailer in the UK, moved to SOA in 2005. Even though they saw immediate benefits, there were other things that were still falling behind in their IT system. There were still 53% of new service designs that were failing governance tests the first time and there was still duplication in some of the services performed.

As a result, they adopted HP Systinet. This SOA governance tool helped 95% of new service designs pass the governance test. It has also estimated that this new software will save them £526,000 over the next three years, due to the avoidance of duplicating processes. It also will allow the IT department to deliver new services to the business in the shortest amount of time possible.

Do you think that corporations selling SOA governance tools are starting to respond more to customers needs?

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/

SaaS Trend in Ecommerce

A recent study by Gartner has revealed that 90% of Ecommerce sites will utilize SaaS by 2013 as reported in this article from ebizQ. The results of the study indicate that Ecommerce sites will use at least one of the following services: product reviews, product recommendations, or social sales capabilities. A statement from Gartner to ebizQ announced that:

“The trend toward SaaS applications has affected customer relationship management (CRM) and other applications, and e-commerce isn’t exempt from this trend. E-commerce SaaS solutions enable companies that couldn’t afford e-commerce to have these capabilities and compete online. It provides organizations with live Web sites, and enables e-commerce SaaS service providers to provide individual services, such as product reviews or click to call, that can be incorporated into e-commerce SaaS platforms, as well as on sites that are using licensed software.”

Gene Alvarez, research VP for Garnter, cautions Ecommerce companies to investigate before jumping to use SaaS tools. According to him it is very important for organizations to

“develop a SaaS strategy that accounts for the scoping, evaluation, selection, operation and different architectures or SaaS solutions, as well as determines the organizations comfort level in leveraging externally provided IT applications.”

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/

Enterprise and Architecture: Where Does the Balance Lie?

Chris Potts reminds us in his latest post on CIO where the balance lies between the Enterprise and Architecture.

He begins his explanation with a definition of Enterprise which is used in economics – the ‘animal spirits’ of the entrepreneur. This is where he gets his expression “the tiger and the toolbox”. Futher on Chris explains how companies must not be too focused on being too much toolbox as opposed to tiger. What does this mean? Companies too often end up concentrating more on frameworks, models, techniques instead being out there in the corporate jungle influencing and shaping the enterprise.

The real benefit comes when the enterprise drives the architecture and not vice versa.

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 definition of SOA

An article at CIO recently defined service oriented architecture as:

a broad, standards-based framework in which services are built, deployed, managed, and orchestrated in pursuit of new and much more agile IT infrastructures that respond swiftly to shifting business demands.

Also according to the article, SOA also has the potential to reduce your IT costs and improve your business agility, all while taking many of the tools already at use in the organization and conforming them to a new structure that will help align the business.

Do you agree with this definition, if not, what would you change?

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/

SOA Presentation

Recently I saw this interesting slideshare presentation that discusses Service Oriented Architecture titled “The Service Oriented Elephant”. Some of the main points that it covers include: Building Blocks of SOA, Organization Roadmap – How much SOA, and Implementation scenarios. Take a few minutes to go over this and let us know your thoughts. Do you have any observations or musings regarding the presentation?

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/

Service Oriented Elephant

view presentation (tags: enterprise architecture service orientation web services soa)

The Government’s Incremental Move Towards SOA

This latest post on the SOA Network details how the latest report from Input, a leader in the authority of government business, discusses that the government’s growing adoption of SOA practices will fundamentally change how it delivers internal citizen-facing services. The federal market can benefit from increased agility and better IT alignment that SOA brings to the table.

Deniece Peterson, senior analyst at INPUT mentions:

"SOA shifts the concept of the application into a highly dynamic and fluid marketplace of plug-and-play services. A function previously performed by one vendor's application could now be completed by a number of discrete services provided by a multitude of providers. The standardized environment required to make this happen could severely impact the provider who relies heavily on proprietary elements for competitive advantage."

It is still early in the process to see a dramatic change in the federal SOA market as SOA solutions are slowly being integrated into the customer’s environment. The findings from Input can be found here, “Service-Oriented Architecture: Implications for Government and Industry”.

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/

At CIO, they recently profiled a chapter from the book Executing SOA: A Practical Guide for the Service-Oriented Architect. SOA can result in the collaboration and a change in the system both affects the workers and the management of the system. Changes in the system can mean behavioral changes in employees and management and changes in the roles of all employees, with cooperation of all parties a high priority.

This article defines the following as important for service oriented people in the enterprise. Here’s the list from the book about managers:

• Primarily act as observers instead of directors (who issue top-down orders).
• Monitor the business (adequate tools and systems support this).
• Define rules and processes, such as building a constitution that includes the fundamental laws for the company (golden rule or constitution).
• Recognize talents and temperaments as well as know the skills of the employees to staff roles/pools (act as mentors for personal development—especially matching talents and temperaments, not just acquired skills and experiences, to the tasks).
• Allow satisfying freedom to the employees under the set rules (equivalent to the loosely coupling of services in an SOA).
• Motivate employees by addressing the individual talents and preferred tasks. (This applies especially to people managers who are responsible for dedicated teams, versus business generals who are in charge of the overall corporate directions and are not dealing with daily execution at the bottom.)

Do you agree with all these points? Would you add any?

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/

Hiring Enterprise Architects

I came across this interesting post today regarding the hiring of Enterprise Architects. It poses the interesting question of by simply hiring and enterprise architect, does that mean that you will automatically have enterprise architecture? This blogger says no. In fact, in his opinion, many companies would like to believe that having an architect qualifies them to say that have architecture in place, but in fact there is more to the process than simply having the personnel in place. The blogger also contends that EA is a “necessary evil” and in order to hire the best architects they

“must be a dedicated and well rounded man that has to apply creatively the existing body of knowledge since the current state does not support well your endeavor to create your enterprise architecture.”

Do you think that some companies simply believe that by having an architect it means that they have an architecture? What are qualities you look for in an enterprise architect, who would need to successfully build a framework for enterprise architecture from the ground up in an organization?

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/

EA Can Not Change the Nature of Your Business

Neil Ward-Dutton provides a different perspective of EA in his latest post on Advising on IT-Business Alignment. Neil states that even though EA is extremely effective, it is at best only shaping the way that IT supports changing business conditions and not “changing” business focus. New forces (new product launches and development, acquisitions and mergers, new regulations) will always drive business to further develop its technology focus. The best EA teams provide a way for organizations to adapt to these changes with the least amount of stress possible. Do you think that enterprise architects are realigning or “architecting” the enterprise?

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/

Enterprise Architecture constantly leads to a competitive advantage

Paul van der Merwe, consulting manager at Real IRM recently took the time to talk about the Harvard Business study and the benefits of strong enterprise architecture. Enterprise architecture can lead to much more than a competitive advantage when it comes to your business. Along with the competitive advantage, EA can bring profits, market leadership and a sustainable business model.

The Harvard Business report showed that these were the effects of having a strong business structure:

* More competitive, especially in terms of entering new markets and launching new products and services.

* More profitable, both through increasing revenues and slashing costs.

* More easily able to embrace change, including regulatory change.

* Able to remove duplicate and redundant processes, including the IT systems which support these processes.

* Able to cut IT costs (by up to 25%), identify payback on IT and more easily merge the goals of business and IT.

* Able to manage their data more easily, with less manual rekeying of data, and reduced data error and redundancy.

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/

Supporting SOA

This article from Collaborative discusses funding of SOA. As the article states, before commencement of a project of this kind it is important for organizations to consider their investment principles, current assets, and option that they have for IT funding. Some other highlights included in this article is that to succeed with funding it is imperative for an SOA initiative to

align with one or more core investment principles, such as:

1. Enterprise Vision & Mission Alignment
2. Enterprise Mission Criticality
3. Enterprise Economy-of-Scale Value
4. Enterprise Risk Tolerance
5. Strategic Leadership Opportunity
6. Interoperability
7. Common Need
8. Technology Maturity

The paper also informs that the basic funding models include:

1. Project-based

2. Enterprise-based

3. IT-based

4. Charge-back

I found the overall article to be very helpful in providing a focus when discussing the need for funding of SOA projects and recommend it for reading.

Reasons Why People are Responsible for SOA Failure

Mike Kavis from Techworld posted this informative article on what makes SOA fail in businesses. In summary he provided these 10 reasons of why people are responsible for the failure:

1. Fail to explain SOA’s businesses value
2. They underestimate the impact of organizational change
3. They fail to secure strong executive sponsorship
4. They attempt to do SOA “on the cheap”
5. They lack the required skills to deliver SOA
6. They have poor project management
7. They think of SOA as a project instead of architecture
8. They underestimate the complexity of SOA
9. They fail to implement and adhere to SOA governance
10. They let vendors drive the architecture

It was interesting to see his opinion on what needs to change in the way in which people incorporate SOA into their respective organizations. What are your viewpoints on what makes SOA work in the workplace? Can you think of any improvements you would recommend for individuals within companies?

The Migration Planning of EA

Alin Ingis at the Chief Architect blog recently took time to discuss the third part of what he believes as the enterprise architecture cycle, the migration planning state.

He believes there are two types of migration plans:

• A formal transformation program – this will typically be a major replacement or upgrade of the IT landscape that underpins major business change
• A set of policies that steers IT change

However, there are always things that do not fall into the categories listed above. He took time to highlight the different types of business cycles that need to be observed so that they don’t disturb the practices being put into place: business cycles and business events. The three types of business cycles that Alin highlighted were: annual financial cycles, business planning cycles, and seasonal sales cycles. Companies always need to pay attention to business events, as they can occasionally put stress on some of the business processes and supporting systems.

Microsoft’s Enterprise Architecture Toolkit (EATK)

Recently, Microsoft introduced a new toolkit in order to help companies structure their enterprise architecture. Mike Walker discussed this new software application in a blog post. Thy initial form is in Alpha and they will only be offering it to a select number of users. Capabilities will include:

• Repository - Meta-data repository for uniting enterprise processes, storing existing architecture assets and a catalog for patterns (Software Factories in Microsoft terms or Architecture Building Blocks (ABB) in TOGAF ADM terms)
• Architecture Management - Portal and Workflow assets that aid in the processes and govern architecture creation through the SDLC or through post production service management processes.
• Strategy Management - Portal and Workflow that aid in the creation of as-is or current state architecture, to-be or future state architectures and the management of technology life cycles of architectures.
• Community - Portal technologies that aid in the communication and collaboration, vetting of ideals through-out the enterprise, communication of Principles, Policies, Standards and Design Patterns, Add-Ins and Templates for architecture development.
• Modeling - Usage scenarios for how to leverage Microsoft Visio to correlate architecture information from the Architecture Meta-Data Repository to Visio diagrams and shapes.

SOA and the enterprise

In an article I found at Computer World, three experts talk about importance of implementing SOA on a company wide basis, not just a project to project basis, and defining the processes to have the enterprise architecture work company wide. Larry R. DeBoever, one of the principals, along with Tim Westbrock and George S. Paras, of EAdirections took time to share their views on what they see necessary for SOA to be best implemented across an enterprise.

Westbrook believes architecture is important to the processes, "A strong enterprise architecture program is vital if SOA is to reach its potential of actually operating across the enterprise rather than being isolated in individual custom application development projects."

Paras belives, "Many people see SOA as a technology, an implementation approach you use deep in the bowels of application development. It really is more of a flexible, adaptive, reusable design approach for disassembling and reassembling an enterprise as it evolves in response to a constantly changing environment."

It is important that the SOA plan of the company is built off of a game plan, as it is vital to know which services need to have processes built for them and how they’re going to be coordinated together. All of this and standards need to be the same across the company in order for SOA to work to the best of its ability.

How to measure the work of an EA

In a recent post at Enterprise Architecture: From Incite to Insight, James McGovern explains how the work of an enterprise architect should and shouldn’t be measured.

He states that enterprise architecture shouldn’t be measured purely based on activity and it can’t be measured from a time perspective. It also shouldn’t be based on artifacts, as these architects create many references to other architectures.

There should be no template to measure the progress of enterprise architecture. It can be measured by viewing improvements in the IT system. Another way to measure this is to look at the management of the enterprise spend, which should be spent in a strategic manner.

What do you think are the best ways to measure your accomplishments of an enterprise architect?

EA Poll

This afternoon I came across a poll in my Google Reader that caught my eye, What does your enterprise architecture group deliver? Take a second to make your selection/s, as I was shocked by the results. Here’s the direct link to the poll.

Finding the Value in Enterprise Architecture

Peter Evans-Greenwood, CTO of Capgemini Australia, released the following presentation about “Finding the Value In Enterprise Architecture” on slideshare. The presentation is very informative, and explains changes happening in Enterprise Architecture and ways to ensure that it still generates value to the organization. Hope you enjoy!

| View | Upload your own

Enterprise Architects can be key in tough times

Yesterday, we told you that enterprise architects are vital to an organization for many reasons.

Today, Forrester released a study stating that enterprise architects could be a valuable asset for today’s businesses given the current economic downturn. The report, detailed here at CIO, states that during this economic hardship, executives will look closely at IT and judge the value of their investments. Enterprise architects can show the executives the areas of the IT departments that can be can be let go as well as the valuable ones.

Enterprise architects should be encouraging executives to prioritize, cost quantified list of the low-impact items available for cuts, the most important things not to cust and the most valuable places to invest any remaining funds.

Another important warning from the report: Technology strategies not only had to be aligned with business goals, but that the business charges them with spotting “game-changing” technologies” and leading their organization.

It is also imperative for the enterprise architect to be a business person above all, as the technology strategies should be aligned with business goals, and the architects should lead their organization when it comes to new technologies.

Confirmation on Need for Enterprise Architecture

The need for institutions to have an enterprise architect has become more apparent, and can no longer be seen as just an opinion as I discovered in this article from Computing SA. A study conduct by Harvard Business report evaluating more than 200 companies worldwide found that companies that decided to utilize and define their enterprise architecture strategies had a significant competitive advantage. Below are the findings on the companies that participated who placed an importance on Enterprise Architecture.

- More competitive, especially in terms of entering new markets and launching new products and services.

- More profitable, both through increasing revenues and slashing costs.

- More easily able to embrace change, including regulatory change.

- Able to remove duplicate and redundant processes, including the IT systems which support these processes.

- Able to cut IT costs (by up to 25%), identify payback on IT and more easily merge the goals of business and IT.

- Able to manage their data more easily, with less manual rekeying of data, and reduced data error and redundancy.

Details of What is Not SOA

Enterprise Architecture, SOA, and other phrases like it have become buzzwords within corporations today, yet sometimes I still find myself struggling to understand the terms. Earlier today, however, I came across this blog post, which discusses how to determine when something is not SOA. Below is the checklist that I found to be helpful:

1) If a vendor tells you that you need to buy a suite to get to SOA… it’s not SOA. SOA means complete freedom from suites and integrated packages.

2) If a vendor is trying to sell you hardware… it’s not SOA. Enough said.

3) If you’re sending out email inquiries or making phone calls to find out what services are out there…. it’s not SOA. Registries and repositories are essential for service discovery and validation.

4) If nobody’s sharing services… it’s not SOA. You can have all the standardized services you can handle, but if it’s services within silos and nothing more, then it’s services in silos.

5) If developers and integrators are not being incented or persuaded to reuse services and interfaces… it’s not SOA. Without incentives or disincentives, they will keep building their own stuff.

6) If your CIO is clueless about what’s going on with shared services… it’s not SOA. To truly function, SOA-based infrastructures need to cross organizational boundaries, and it takes someone at the management level to bring these efforts together. Otherwise, again, it’s services in silos.

7) If the IT department is running the whole show… it’s not SOA. Sorry IT folks, but SOA needs to have the business heavily involved in the effort as well.

8) If it only runs one operating system or platform… it’s not SOA. SOA has nothing to do with any single OS.

9) If it replicates a SOA in place elsewhere… it’s not SOA. Every company has unique business requirements and processes, and no two SOAs will be alike.

10) If you have to rewrite or redesign code to make things run right… it’s not SOA. SOA is supposed to make rewrites unnecessary.

Role of an Enterprise Architect

I came across an interesting post on the IT Knowledge Exchange from Anton Venter in which he describes what the ideal role of an Enterprise Architect should be. One of the important factors of an enterprise architect is the ability to hold both a macro and micro view of business strategy. An architect must have knowledge of the architectural approach (macro view) and must also be to work with individual projects (micro view), merging both views together for successful implementation.

Today’s enterprise architect must understand business problems and know what technology is needed in order to provide solutions for it. What’s your take on the role of an enterprise architect?

Why do many IT professionals reject Process Oriented Approaches like CMMi?

I recently came across James McGovern’s latest post on his Enterprise Architecture blog where he explains why IT practioners tend to stay away from CMMi. Software developers are generally used to some kind of structure when dealing with open source; CMMi lacks rigorous structure and so it might be difficult for developers to understand. What’s your experience with dealing with process oriented approaches?

What exactly is EA?

If you are searching the web for a description of Enterprise Architecture, chances are you will come across various translations. This is because there is not one set definition for EA. I’ve encountered this handy list of different interpretations of Enterprise Architecture compiled by Roger Pedroso across various sources at the IT Knowledge Exchange. I’m sure you’ll find it just as useful. Here’s the list:

1. Enterprise Architecture is a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks.

2. An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization.

3. The EA is:
What: The structure of an Enterprise and its blueprint describing.
How: How the Enterprise operates and the processes executed by.
Whom: People.
Which: The technology implementing processes.
Where: Showing the location of people and technology.
Why: To streamline, align, blueprint, strategically plan, and confer agility.
When: According to the Enterprise transformation plan to a target state.

4. Enterprise architecture is an agency-wide framework for incorporating business processes, information flows, applications, and infrastructure to support agency goals.

5. Enterprise architecture is the organizing logic for business processes and IT infrastructure.

Navy is Implementing a Federated Approach to Enterprise Architecture

The author of this article from Federal Computer Week reported about the complexity of the Navy’s enterprise architecture:

Mapping the navy’s interlocking systems of systems is comparable to creating an architectural plan for a city or several cities.

Dan Slick, Navair’s deputy chief information officer for enterprise architecture concurred, “We wouldn’t think of not having a blueprint for a house. The problem is, we don’t have a city plan.”

In response, the Naval Air System Command is creating a Center of Excellence for Enterprise Architecture in order to improve their systems planning. This is being set up following an already successful test program using the innovative federated approach to enterprise architecture. Booz Allen Senior Associate, Frank Brady, described reasons for implementing a federated approach to architecture:

Just as a city plan doesn’t include every detail about every building in the city, an overarching federated architecture must be generalized. Rather than try to model the details of specific systems, a federated architecture should represent activities. Systems come and go, but activities performed by an organization remain relatively constant, he said.

Revisiting the Promise of SOA

As part of this blog, we like to bring you the latest up to date information from across the EA industry. If you didn’t get a chance to view the latest webinar yesterday brought to you by EAC, here’s a great opportunity to view the archived recording of “Revisiting the Promise of SOA” presented by Peter Salvitti of Collaborative Consulting. In this webinar you can expect to learn:

• Whether the adoption rate of services is deep or wide (i.e., related to specific business need or simply a technical service)
• Where reuse is gaining traction in organizations
• How to fund your SOA initiative and who is paying for what
• The fundamental building blocks that should (must?) be in place
• How to navigate vendor marketing

Definitely take the time to view it at your own leisure as I’m sure you’ll find the information very valuable.

Progressive Software buys Iona Technologies

Iona Technologies, known for their specialization in service oriented architecture and middleware specialties, was bought by Progressive Software for $162 million, which equals $4.05 per share, according to this article at EWeek. The deal was announced on Wednesday, June 25. Board members at Iona universally approved the buy. Progressive hopes this purchase will put them into a key position to battle for the SOA market with their current status and the expertise of their newly acquired purchase.

Iona will be operated as a subsidiary according to this article at Information Week, and Iona will continue to sell the Artix Web integration and Fuse SOA lines.

Requirements for EA Lingo

According to this article here at Inside Architecture, a business is a collection of different people, and when working on projects across the organization, we need to make sure everyone is using the same words to ensure understanding across the enterprise.

It’s very easy to use the same lingo from project to project, but even more difficult to communicate the lingo across the enterprise unless a system is set up. The goal of an organization should be to create an understanding across all departments and divisions across the enterprise.

Inside Architecture believes that your goals should be:

• Create a simple information model for your enterprise
• Create a consistent understanding between the people involved in the project

All of this should be done before any type of software is built for your company. If consistent terms are not settled upon, your software will be a waste, and risk your future projects.

Red Hat extends Beta abilities

Red Hat has recently announced, detailed at this article at EWeek, that it will release its beta ability for its JBoss Enterprise Application Program in collaboration with Amazon EC2. This extends the existing relation Red Hat and Amazon have working together.

Craig Muzilla, the vice president of the middleware business unit for Red Hat, had this to say about the new ability of the software:

Java developers can develop an application and deploy it into the cloud without hardware or a data center, JBoss is a core application server with infrastructure, such as messaging and transaction management, for Java developers.

Alignment in Enterprise Architecture and IT

In a recent post by James McGovern at Enterprise Architecture: From Incite to Insight, he discusses the difficulties in aligning what your IT department understands with the priorities of your business, and how that could be difficult to do. In order for these two to function at their greatest capacities, IT and the businesses priorities must be matched to the company’s growth strategy. However, simply doing this doesn’t guarantee improvement.

McGovern also states that being aligned unless IT is held up to the standards of finishing their projects on time and on budget. To have the business and IT completely in sync, the Enterprise Architect must understand the difference between being aligned and being efficient, and hold the IT department to those standards.

Technical Competence is the Bare Minimum

Enterprise architects are generally too involved in reading books within just the technical realm that they forget about the business model and design. Architects must take the next steps to broaden their horizons to make sure that they do not become single-minded. Raf Cammarano makes a few suggestions of different genres that architects should read in his latest post:

Personal Effectiveness and Branding

This is very crucial in terms of saving time, and making sure that your effort is effective.

Innovation, Entrepreneurship and Leadership

No one can teach a person how to be innovative, an entrepreneur, or a leader…but you can certainly pick up some tips to help you out.

Sales and Marketing

You must be able to sell and pitch your ideas to the rest of the company, don’t rely on your technical skills to speak for itself.

Personal Relationships

Lastly, organizations are filled with people so that means that you must learn how to deal with them on a daily basis. People will often disagree with decisions; learning how to deal with them and different personalities will aid you with your day to day responsibilities.

There is plenty more out there to read, but this is just a start for architects to “think outside of the box”.

Making Enterprise Architecture (EA) Strategic with Business and Information Architecture

Business agility is something EA has struggled to enable. Sohel Aziz of Infosys Technologies has put up a great presentation on Slideshare where he discusses how integration of EA at the business level and maturity across dimensions will help drive business agility to new heights. Take the time to view this slideshow as I’m sure you’ll find it extremely valuable.

| View | Upload your own

SOA: What are the emerging Challenges?

In a recent interview at SOA News, Brian Nally sat down with Rami Jammour to discuss what’s happening in the world of SOA. Nally asked what some of the emerging quality challenges for SOA were.

Nally responded with two things:

1) Environments are more and more heterogeneous, with many different faces and protocols

So, having said that given that situation, when you talk about quality you have to make sure that your business processes run on top of these heterogeneous environments need to be validated. You need to have a framework that is flexible enough to drive your process and drive your testing activities across these different heterogeneous environments.

2) People became more familiar with the processes, they began to look at the end processes.

So, they start to ask, what about my legacy applications, or the mainframes, or the green screen? They look more at what kind of framework can give them the flexibility so it can be extended to help them with all these specific needs that they have. Having a framework that is extensible and that can support some of the common things that people do is becoming more and more critical.

What do you personally seee as the emerging challenges for SOA?

EA Functions

Yesterday, I posted on how architects must have a business oriented approach when first creating frameworks for enterprise architecture. Similarly today, I found a post from Inside Architecture that sums of the business function of EA by explaining these 3 segments

• Enterprise Architecture as Technology Planning and Alignment
• Enterprise Architecture as New Technology Innovation
• Enterprise Architecture as Standards, Methods and Best Practices

There was even an image in the post of the process flow of enterprise architecture which include business groups, business leaders, process management, IT Dept, and stakeholders. It’s a good visual for yesterday’s point that architects must coordinate with different business concepts in order to make enterprise architecture valuable. Click on it to see it full-sized.