In a previous article, the spotlight fell on three biggest risks the Chief Architect needs to manage before moving onto something less tactical.  Consider now the area of strategic planning and opportunities in your future state landscape.  Three key sources that the chief architect needs to explore are:

    Read the rest…

Chief Architect’s Big Three Strategy Secrets

Sounds like a pretty salesy headline, doesn’t it?  Well – I’ve got you reading and that was my intention.  It’s the same attention that you need to pay to your enterprise, your business or your organization.  Times are tough out there, and companies need you more than ever to demonstrate Read the rest…

Chief Architect Absolutely Guarantees Value

How can the Chief Architect Absolutely Guarantee Value? Why does the business demand change?   This is the fundamental question you should asking yourself as a Chief Architect before doing any architecture work. Many current IT strategies and architectures are failing. Senior business executives report that fewer of 25% Read the rest…

Way too long since the last post – mybad.  Too much book! Sounds like a pretty sales-y headline, doesn’t it?  Well – I’ve got you reading and that was my intention.  It’s attention that you need to pay to your enterprise, your business or your organization.  Times Read the rest…

Enterprise Architecture Benefits

Enterprise Architecture – Benefits

  • Environmental Factors
  • Large applications are complex and incorporate other applications & components.
  • Need for standard interfaces and products
  • We continually need to accommodate change, and a review of our infrastructure each time we need to make a change is cost and time prohibitive
  • System design modifications & upgrades now are needed on weekly or monthly schedules
  • We are finally building applications that we expect to change, and need to have a solid, well thought out foundation on which to build them

Expected Benefits

  • Improved alignment of IT solutions with business strategy
  • Greater ability to set realistic IT goals
  • Enhanced enterprise information sharing
  • Reduced software and data redundancy
  • Reduced information systems complexity
  • Greater reliability at implementations & updates
  • Reduced dependency on key resources
  • Improved accuracy in scheduling software development / implementation
  • More accurate forecasting of development and support costs
  • More efficient deployment of technology solutions
  • Increased traceability

Tangible Benefits

  • Promote better planning and decision making
  • Improve communication through standardized vocabulary
  • Views communicate complexity and facilitate management
  • Enable strategic use of emerging technologies
  • Read the rest…

It’s nearing end of summer and slowly, folks are getting back from vacation or they are out shopping for school supplies.  Maybe a last minute golf game with friends, or perhaps colleagues.  A day at the beach if weather permits.  As we see the first signs of the leaves turn Read the rest…

And What’s the Difference?

It’s been a long time since I wrote part 1, but I’ll try to get the next few parts out asap.  If you recall, I was writing about the purpose and reasons for Enterprise Architecture. Along with planning and strategy, execution is critical.  We must create and tailor Read the rest…

A New Day for Great IT Architects

Monday is as good as any to do something new.  For most, above average.  Well – today I figured I’d **make** the time to move this blog to the Architect Boot Camp site.  Here it is – hope you benefit from it and I do have plans (hopes) to post Read the rest…

The Enterprise Architect Purpose…

 

Part 1 of 5 part article…

 

The primary purpose of an Enterprise Architecture (EA) is to inform, guide, and constrain the decisions for the enterprise, especially those related to IT investments.

The true challenge of enterprise engineering is to maintain the architecture as a primary authoritative resource for enterprise IT planning. This goal is not met via enforced policy, but by the value and utility of the information provided by the EA.

In general, the essential reasons for developing an EA include:

Alignment—ensuring the reality of the implemented enterprise is aligned with management’s intent

Integration—realizing that the business rules are consistent across the organization, that the data and its use are immutable, interfaces and information flow are standardized, and the connectivity and interoperability are managed across the enterprise

Change—facilitating and managing change to any aspect of the enterprise

Time-to-market—reducing systems development, applications generation, modernization time frames, and resource requirements

Convergence—striving toward a standard IT product portfolio as contained in the Technical Reference Model (TRM).

Selling EA vs. Building Support

The single most difficult task in delivering and developing and Enterprise Architecture program is gaining support from the enterprise itself. This is why I was so passionate about writing this report. There are many bumps and detours along the way, and if we all can avoid and maneuver them, EA will advance as a whole and become more accepted and understand.

There is little reason to start an EA program itself unless it is supported by the business and treated as a business initiative. It will require executive level commitment and persistence. The IT department should not have to continually go to the well in various user organizations to get their support if there is a good plan and strategy in the beginning.

Want to read the rest? Get my Ten Secrets to Selling Enterprise Architecture and download the entire 33 page article.

** Note – As of Jan 1 2009, this report is no longer available publicly.  If you want the details, go to our Membership Portal ** Read the rest…

Recently, one of the people I have been coaching in the area of Enterprise Architecture asked me a great question – one worth posting here. He said “what is the scope of the Enterprise Architect?” in context to the head of Application Development, the Lead Analyst or the Solution Architect. Read the rest…