Gartner: What they say about the place for Enterprise Architecture 2010 forward

The following article :
http://biztech2.in.com/india/news/enterprise-solutions/enterprise-architecture-enters-trough-of-disillusionment-gartner/88972/0 argues to the point of how EA when mature should be the bridge to help Business Strategy become IT Strategy ... not vice versa. Business Strategies should always drive Technology. You don't start with a Technological solution or Tool and try to mold the business around it.

Here is an intresting quote from the Article:

"The artificial walls between business and IT are crashing down, and EA is the bridge to integrate business and IT," said Philip Allega, Research Vice President, Gartner. "EA's original promise was its ability to provide future safe guidance given the desires and vision of an organisation's senior leadership team. As IT roles shift away from technology management to enterprise management, EA is suited to bring clarity to these blurred boundaries, and, by 2015, increased adoption of EA processes and uses by business will further IT's alignment with the organisation's culture, future-state vision and delivery of business value outcomes."


I agree with this assessment.

Bridging the gap between Information Technology and Business

It is always a challenge for highly technical people to productivly communicate with innovative business people. The approach and language at times seems like opposite ends of the same coin. I ran across a good article that expresses some nice ideas for bridging perceived gaps. Isn't it funny how two people can be talking about exactly the same things and to them it appears that they have different opinions based on word choices, mindsets, or preconcieved perceptions :-)

Here is the top six list from the article:

1. IT is a cost center
2. The cheapest way is the best way
3. IT is a back office function
4. We speak different languages
5. Technology is its own island
6. Business and IT have different goals

I have seen many presentations lately .. some with quotes from Gartner reports .. that show that the industry is fast moving to bridge the past perceptions of a great divide between Business and IT and to merge the goals of both practices. It just makes more sense to both entities to integrate thier visions and communication into a more strategic vision to drive the success of the company.

Also, if you have enjoyed being in the IT bubble and have been able to build a career in that comfort zone those days are coming to an end. With offshoring and other avenues for cheaper commodity based development, an IT person in the United States will need to be able to demonstrate business value and innovation ... not just IT skills to hold their value with the company. Excellence in technological concepts and practices will only get you part of the way there ... business savvy and great interpersonal skills are going to carry as much value as deep experience in technology.

Here is a link to a very good article on the topic:

http://www.dorseyplus.com/Img/pdf/1943.pdf

The argument of simplicity vs. complexity

- Albert Einstein

"The significant challenges we face cannot be solved by the same level of thinking that created them.”
Also,

- Oliver Wendell Holmes

"I wouldn't give a fig for the simplicity on the near side of complexity; but I would give my right arm for the simplicity on the far side of complexity."

What the combination of the two means to me is that significant challenges cannot be solved with simple quick fix solutions.

I wish that I could take credit for realizing this, but the concept was borrowed from the book "The 8th Habit" which is Stephen R. Coveys followup to his bestselling "The 7 Habits of Highly Effective People".

I believe that this concept applies to IT Architectural and Engineering practices just as it does to business and daily life. The quickest path to solve a given problem isn't always the best. Granted, not every problem requires the complexity needed to design the space shuttle but if your companies bottom line depends on the software that you deliver you had better put the time in up front to determine the design and metrics needed to gurantee the projects success. Keep in mind though that even the most complex problems can be broken down into small enough tasks to make it palatable to development team members of all skill levels.

An opinion on outsourcing

Not sure I agree with this in totality, but it was an intresting read nonetheless.

http://www.soc.duke.edu/GlobalEngineering/pdfs/media/FramingEngineering/InsiderHigherEd_QualvsQuan.pdf

I am a big proponent for Quality vs. Quantity in software engineering. Maybe the same applies to engineers?