You have arrived at this page because you have indicated an interest in the Enterprise Architect Boot Camp workshop.

For more information about the schedule and offerings, please click the training link and follow the path for schedule.

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:

1. CEO’s Top Strategic Drivers
2. CIO’s Primary Concerns
3. Enterprise Portfolio Management

In fact, the CEO owns, knows, eats and breathes their top three strategic drivers.  At a time in the economy that we are facing now pure survival may likely be their number one focus.  Such drivers might include the area cost savings, as well company stock prices.  The chief architect needs to fully understand how these drivers impact or are impacted by the Enterprise Architecture Plan.

Figure out plan of attack

Choices made in the areas of infrastructure and solutions will most likely be efficiency based, and risk averse.  Creatively considering ways in which the architecture can contribute in the area of competitive tactics is another way in which we can provide value.  If the CEO is really focused on their competition’s moves, it might be a looming takeover or collapse.  How can the strategic plan allow for agility in these types of circumstances?  What would it take to expend with a line? A division?  Or purchase either?

An additional area of CEO concern is major projects.  The CEO realistically needs to keep aware of the biggest corporate expenditures and these may be IT projects.  Characteristically these are very high profile projects or large replacement projects.  The chief architect should be fully aware of what the CEO’s concerns are, and what it is troubling them about the projects.  It may be the board’s opinion of the project, or where else the money could be better spent.

The second area the chief architect needs to focus on is the concerns of the CIO.  It is crucial to have a list of things that keeps this soul up at night as well.  Some risky hardware component or some recent security lapse could be top of the list. It might be an employee or staffing issue.  Where they are privy, the chief architect needs to explore what can be done in upcoming plans.

Ultimately there is the major issue of job retention as a CIO.  Budget cuts and less than stellar IT performance can be used as stimulus to look within the large resource pool available.  What can be done to ensure IT performance is not a factor.

A major area of concern to the chief architect should always be enterprise portfolio management.  This is the prime source of where strategic future directives will be exposed.  The architect needs to comprehend and be fully aware at all times of the biggest opportunities.  What was the biggest project or investment identified?  What is on that list or that requires the biggest investment AS WELL as the biggest return on investment.

I would suggest that the chief architect to quickly scan that portfolio management list on a monthly basis and retain a list of the quick wins and low hanging fruit.  Each of these should be incorporated into whatever future planning is being pursued as the opportunities are available.

You’ve got to keep the pulse on these critical elements – and keep this in on your laser focus.  Continually update your enterprise architecture plan where you can whenever these strategic drivers change.

Happy Architecting

Sharon

It’s been far too long but I’m writing again – you see I’ve been writing a lot since I last wrote and so there are lots of pieces that should be appearing here soon – I’ll just have to figure out where to start.

I’ve been doing a lot of research lately on the resources available today on IT Architect Careers.  There isn’t much – a handful of books, a few websites and a couple of education offerings.  Career development has been a passion of mine for nearly 25 years – not sure why but I am fascinated to get a hold of the career section in the paper and have always been a go-to person when my colleagues and teams in architecture have been trying to decide what they might explore next.

I’ve decided it deserves to be in print and it’s been a work that’s been developing for nearly two years.  I finally have a name for this book that’s due from the publisher now April 28th, 2009 and it’s called “Architecting Your Career:  Build a Roadmap for Excellence in IT Architecture”.   It’s a partner to my architect career portal and so I’m so excited about it.

Here’s where you come in – I need to know the answer to this burning question as I’m trying to develop some bonus items for my book that will be accessible to those who buy it.  You can help by providing the answer to this one question.

Architect Abstract Ask Contest

At the end of the week, my assistant and I will draw the name for one who provide answers and they will win three free months membership on the career portal.  Deadline is February 28th, 2009

Happy Architecting!

As I spend time coaching & training others in Information Architecture, and consulting in various types of architecture, I am finding out that more people that I would have guessed have been through format Zachman training. As this is a formalized approach, I am not surprised to find that many have been instructed to not only use his framework, but to “fill it up”.
Read the rest…

I am continually faced with the same question from my clients who are contemplating the EA journey. They want to know how to justify the investment and time, and can’t seem to get the Executives to get past the mere suggestion of the topic. In the past, I attended two interesting sessions on Disaster Recovery Planning and a status check on Sarbanes Oxley.

As usual, both brought me back to thoughts pertaining to EA. I am still amazed by those who will fork out the mega bucks to pay for a one or two year project on DR, but won’t let any conversations roll on EA. My suggestion have always been that if we had EA, we would spend a mere fraction of the time on DR. Most DR’s fail because they focus on planning out EVERYTHING instead of what is important. They are too granular too early, and would be much more successful if they included some good scope planning.

Now many of you are still wondering what this has to do with power, and inventory. A few years back I did some work on an Enterprise Architecture Plan for a large organization. They hired me to review their framework and their ERP to date. When I asked where the current state section was, they said “Oh, we don’t want to spend money on that – we know what we have – the value is in the target”.

Don’t worry – I’m not going to get into a huge lecture on EA strategy, nor on the whole EA Process. This comment is more common than you think. Do you know how many IT organizations think they know what they have, when they really “roughly know” what they have. When it comes time to make any serious decisions, do they really know how many servers have how many and which applications running on them with which databases for which business processes? I doubt it.

Any if they did roughly know, why do you think almost every technical or application project starts out with the same analysis? “Well, we’ll just send someone out to find out which databases run on that server before we upgrade it.” Another comment might be – “well, we need to change that business rule – can you find out which parts of the application are affected”, or “which systems are affected by this legislation change?”

This is so common and the amount of work incurred to answer these questions over and over again is never accounted for. It is sucked up into the project in question, and little thought is ever given to the value of the Enterprise Architecture. Many will acknowledge that if they had it, some of these questions would be easier, but we haven’t put a specific value or cost of not doing it together, making it forever impossible to get it approved!

My comment for today is this – the power is in inventory. Current state is in part just that – taking into account what you have and how it is related. My comment earlier regarding the organization that didn’t want to spend time on current state because they didn’t have the time to go out and inventory all of their departments. Guess what?

They still don’t have an actionable EAP, and as far as I know, their EA Project has stalled. You can’t really figure out where you are going unless you know where you have been, and if you can’t budget for an EA Program, a good start might be creating small, incremental inventories each time you have a large project, slowly whittling away at the problem.

If not security, probably the hottest topic in IT Architecture today is Services Oriented Architecture or SOA. I’ve actually heard some folks say “We’re not getting trapped in the buzz around Enterprise Architecture – we’re doing Services Oriented Architecture”. No kidding – I heard this at a computer organization dinner this week, and yes, the comment was made by a manager, not a “techie”.

This article will focus on the need to include SOA within your EA.

SOA – A Major Building Block in Enterprise Architecture

Service Oriented Architecture is not meant as a new way to define Enterprise Architecture, but it definitely needs to be a major focus of both the application architecture and technology architectures.

When building our Enterprise Architectures, many organization fall into the trap of believing that they need to create models, principles, guidelines and standards on every part of their environment. This is usually why it is never completed, the projects are shelved and budgets run dry.

Successful organizations create strategies to build their Enterprise Architectures in an iterative manner, focusing on the framework and basic components first, and then moving on to add critical models and detail sections of the architectures piece by piece as IT initiatives dictate.

SOA should be viewed as a “sub-architecture” of the Enterprise Architecture, one which should be a primary and early focus. Many organizations will have components of architecture for connection and messaging capabitilities needed for SOA. These should be heavily documented in great detail, and the EA strategy should include a communication strategy that shouts from the rooftops that this architecture is available and ready for prime-time. Development teams should consider this architecture first when deciding on methods for their current projects.

SOA using web services will allow us to support today’s flexible needs of business. Our architectures should include, whether bought or assembled, most of the services we will need for our Enterprise Architecture. As new business initiative arise, we add value by reusing existing services that we have proven to be effective, and building or developing new services that give our organizations some type of competitive edge or fill our unique business needs.

Our enterprise archiecture, built within the confines of one or a few selected methodologies and framework will include views, abstractions and models. The basic components of the SOA infrastructure are paramount to our successes and must be modeled in detail in order for us to encourage the use of and support applications that will be built to give our business departments the edge.

Information and organizational technology requirements don’t really differ much between organizations. We all need customer, contact, accounting, financial, purchasing, human resources, and security solutions, just to name a few. Services and components will eventually be available to meet all of these needs in a variety of ways. We need to architect our systems and environments in such a way that we will be able to use these generic types of point solutions.

The uniqueness or competitive needs of our organizations and our business architectures will beg us to use solutions such as SOA to focus on the development needed, rather than the plumbing. We’ve all heard SOA is the next silver bullet, but there is work involved in accepting and including it in our architectures. The next models you build should embrace these thoughts and models, components and services to support this direction should be high up on your “to-do” list of models to be built.

Trends in Enterprise Architecture – October 2004

– A reprint from the Canadian Information Processing Society Magazine December 2004

As I return from the Enterprise Architecture Conference held in San Diego, I reflect on the advancements described in the field during the conference. Trending is likely my primary purpose for attending – putting a finger on the pulse of this once uncommon area of IT can indeed be exciting.

How can this be interesting you say? – well, you are going to have to work with me on this one – excitement grows when you realize others either share your successes or your dilemmas, and also when people gather to listen to “how-to” seminars in some of the trickier challenges in the EA world. I am going to attempt to share these trends, and also paint you a picture of the founding father of EA and his view of the world.

Trends included enhanced focus on the linkage between Portfolio Management and Enterprise Architecture. It was refreshing to see ways in which Architects can finally find ways that reflect real and near-time value to those in our organizations who are planning projects. Doing the right project at the right time has always been a goal, but now I feel that it is a realistic one, if we can in fact convince organizations to take Enterprise Architecture seriously.

Portfolio Management presentations focused on methods of grouping or categorizing enterprise architecture target state goals and IT investments, as well as methods to evaluate and prioritize project directions – again, similar to traditional implementation planning within the EA, but focus is on elevating discussions between IT and business leaders such as Project Managers and Portfolio Directors.

Another trend evident at the conference was the difficulty many organizations face in engaging business to become involved in Business Architecture. As a component of the EA, it has been traditionally difficult to search out a business strategy that IT can attempt to align itself to. While we in IT want better credibility and to show better value to the business, we cannot realistically achieve this goal if we are not completing projects and focusing on architecture that will advance the strategies of our organization.

Sessions at the conference went into great detailed methods for extracting the business strategy, if only by research and validation, so that our Enterprise Architectures can have a valuable focal point at the front end.
Additionally, the strategy and process around creating an Enterprise Architecture Plan has been packaged and labeled by META Group – which usually means that the “how” will assist organizations in gaining traction on these endeavours.

Again – it is visible in how META has been aligning steps within the EA process with traditional project management techniques – they have labeled the Enterprise Architecture Strategy as the Common Requirements Vision
component of the EA – a little cryptic, but can perhaps be a little more easily understood, especially by those in the Portfolio Management space.

There were good consultants who spoke of Governance and Business Strategy. Not much new in the Governance space, although a few good presentations really walked the attendee through some of the more difficult or rough spots.

Business Strategy is not necessarily a common skill or interest to those entering Enterprise Architecture, so several good presentations on thinking strategically, and extracting information from common business documentation to form strategies in order to have business executives validate them as a substitute for having the real deal.

While there were many instances of terminology that have been relabeled with new nomenclature, and have been clarified for those struggling with many of these complicated concepts – one component remains the same – The Zachman Framework. John Zachman is indeed alive and well, and is presenting keynotes at this conference annually with the same intensity. For those of you not familiar with JZ, he is considered to be the father of Enterprise Architecture, writing a paper on his 5W framework in the early 70’s.

He was livelier, than even I had remembered – essentially using 75% of his allotted time slot for one-line zingers and intense comedy relief around – you guessed it – Enterprise Architecture. He continually talked about how conference providers were continually exasperated with him as he yet again returned with good-old plastic film overhead slides.

I glanced through out handouts, and there were likely fifty slides provided by John. With 25 minutes remaining, he’d yet to look at one – except for his title page. He bantered about how time schedules for IT projects were continually decreasing and he approached his final message.

John pretended to show us a secret slide coined purely for the Microsoft conference he had recently attended. It was a list of all of the problems that were present in IT in the mid 70’s. Ever familiar issues such as poor analysis, programs with too many bugs, or the components didn’t fit well together were on this list. As he progressed towards the bottom reading even more quickly – the laughter grew stronger – people were really eating this stuff up, and he still hadn’t touched a slide or told us anything new.

He flipped to a slide reflecting problems in IT in 2004 and coincidentally it was the same list. He had talked throughout his speech about the processes that aircraft engineering companies used to ensure they created the right products, on time and on budget – and especially an example where Toyota could build any one of their cars in a five day build cycle. He talked about being able to mix and match their standard pieces. He returned to the IT list of issues, and told us that as organizations, we had no hope of ever achieving the delivery schedules that we are now faced with, with the methods, processes and tools we use today.

John enforced that our only hope was to do things differently were indeed through Enterprise Architecture, and impressed on all architects present, that we were responsible for making this happen. With that burden impressed upon us, I thought what could I do to achieve his challenge? I am just a consultant who helps clients in this area, and more are interested in architecture for specific solutions than for their entire enterprise.

I concluded that it was going to still going to have to be through an education process, but in fact sharing many of the techniques that had been presented on some of the more difficult stumbling blocks was the best that I could do, without wandering down the streets of Winnipeg, or taking out full page ads in the newspapers and screaming from the roof tops that this is our only salvation.

EA is in fact alive and well, and if you haven’t visited the topic lately, I encourage you to again review what’s new out there and how this can help your organization.

A brief description of the main components of an Enterprise Architecture:

The following are components of an Enterprise Architecture. Each individual component is part of the Framework.

1. The business architecture component analyzes the company’s business drivers, opportunities, goals, objectives, and strategies. For instance, does the company plan to develop new product lines, infiltrate new markets, and reduce operating costs, or increase customer satisfaction and loyalty? What are the most critical business problems or opportunities? The business-architecture model also provides a high-level blueprint of all critical business events and processes, along with a description of their relationships and interdependencies.

2. The organizational architecture entails a comprehensive examination of current IT processes, services, organizational structures, roles and responsibilities, and core competencies. All these components are carefully analyzed to see how well they facilitate the creation of flexible application and technical architectures that can quickly adapt to support new business requirements. It may also be referred to as the operational architecture by some.

It addresses fundamental questions such as: How well are IT services managed? How well the IT organization does contributes to the overall enterprise’s success? Are IT services closely aligned with the business strategy? Is the current IT technology infrastructure a barrier to supporting or expanding business?

3. The application architecture lays down the core business applications required to enable business processes and successfully run the business. The application architecture model encompasses all legacy systems, software packages, and distributed systems, along with an appraisal of their strategic value and impact on the business.It also identifies the new applications that are required to satisfy up-and-coming business needs. An assessment of the health of current applications is equally important to include, Fournier says, both from a functional and technical standpoint. Finally, the application architecture must carefully analyze the interdependencies and interoperability needs that are required between business applications.

4. The information architecture examines the key information assets of the enterprise. What are the types, locations, and timing of information that are required to achieve the prime objectives laid out in the enterprise business plans and processes? What types of information need to be shared? In what state is operational and informational data? The creation of the information architecture model also encompasses building an inventory for all operational files, databases, data warehouses, and data marts that are required by current and planned business applications.

5. The technical architecture model scrutinizes the underlying technologies that are required to run the applications, such as computing platforms, networks, operating systems, database management systems, storage devices, and middleware. The technical architecture model can be broken down into specific sub-models, such as platforms, networks, security, and more. For example, some companies have developed a comprehensive security architecture blueprint to enable e-commerce in a secure fashion. Throughout the construction of the technical architecture model, potentially overlapping or incompatible technologies are identified, and those that do not make the grade become candidates for being phased out.

The following example is a scenario in which the EA was used in setting Budgeting Strategy Direction

The following describes a scenario in which the Enterprise Architecture may be leveraged for pure business benefit:

A snippet from one of our case studies at Firefli Consulting Inc.

Eventually, we decided to reorient our architecture efforts toward providing the context and facts to guide planning decisions. But first we have to do some work. For example, if an IT department already has a well-defined technical architecture, but was focused on technology and tool standards, IT may have little connection to business applications. To supplement it, we might develop several architectural deliverables.

* A model of the business that identified key processes, constituencies and business capabilities.
* An inventory and map of the current state of our business application portfolio. We then overlay that on our current technology infrastructure.
* A target state for the business application portfolio.

With these in hand, we can engage in the next year’s annual planning process. We can map the proposed projects to the business model to see how projects related to each other. That allows us to identify project overlaps in terms of common or related business functions, such as data marts with a high degree of common information.

When it comes time to prune the list of proposals, we could suggest consolidating projects so that one single effort could support more than one business need. The overall economics of the consolidated projects is improved-more business benefit for a given unit of investment-and so was their priority for funding. IT resources could be focused on a smaller number of projects, resulting in higher quality and more reliable delivery, as well as a reduction in subsequent application maintenance.

Similarly, we might uncover many situations in which business areas are proposing projects that overlap with applications already existing in other areas. Because our IT groups may work in silos to some extent, they would not have been aware of the redundancies. We can now identify those cases and recommend either building on the existing applications or slating them for replacement.

Our architecture approach can allow us to proactively assess the fit of proposed projects with the current technical architecture and provide early on a critical heads-up of the risk or cost that will be involved when the fit is not good. Software upgrade plans, meanwhile, can now be compared with the proposed projects to see where they could affect a project’s timing or the cost to perform the upgrade. The project’s estimated cost is then adjusted to reflect this.

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
• Improve consistency, accuracy, timeliness, integrity, quality, availability, access, and sharing of IT-managed information
• Allow the Assessment of benefits, impacts, and capital investment
• Analysis of alternatives, risks, and tradeoffs
• Opportunities for building greater quality and flexibility
• Achieve economies of scale by sharing services
• Expedite integration of legacy, migration, and new systems
• Ensure legal and regulatory compliance

The EA Provides Leverage – In Planning & Decision Making

• Provides Continuity for short term leadership and planning
• Allows coordination of IT changes with business initiatives
• Provides a commonly known solution space with Business direction and strategy information
• Provides a migration strategy to steer technology decisions
• Provides architectural views to analyze emerging technologies – Allows IT to Consistently apply technology within its’ lifecycle
• Ensures legal and regulatory compliance for each business decision
• Offers Quality and flexibility application opportunities
• Allows IT to manage change effectively
• Models & frameworks can identify overlaps and opportunities for consolidation
• Allows reconciliation within known boundaries where possible as change occurs

The EA Provides Leverage – In Managing Costs & Assets

• Improved decision making tools offer more investment protection
• Allows the Enterprise to allocate funds to replace systems & equipment before life-cycle end
• Provides a multi-year planning and budget strategy for projects and infrastructure
• Allows IT Management to limit resources dedicated to “Legacy” architectures; schedule their replacement with Technology refresh.
• Provides a controlled environment for “evaluation projects”
• Allows IT to invest in appropriate education training
• Allows IT to seek out Economies of scale opportunities – share services, technology, apps & data

The EA Provides Leverage – In Communication

• Provide a reliable communication infrastructure for business opportunities
• Manage services effectively
  - know what you have
  - what you need
  - what you will need
  - who will manage

• Benefits and methods to business communities & ways to employ modern technologies
• Standardized vocabulary

Leverage – Utilize

• Utilize standardized products and environments where possible
• Use target architecture to address the need for interoperability and to standardize data interfaces
• Evaluate business processes for redesign opportunities before automating them
• Implement contemporary, proven technologies
• Introduce new products through pilot projects through appropriate benefit and cost evaluation before adoption
• Ensure H/W & S/W adheres to open stds & minimize proprietary solutions
• Look for Data Sharing Opportunities
• Identify reuse opportunities, components, etc. Apply existing blueprints to accelerate system design and development
• The EA approach reduces the number of IT products, reduces system maintenance and operational costs, and simplifies staff training.
• Leverage technology evaluations and feasibility studies; prototypes.
• Leverage core processes and capabilities of business units.
• Leverage back end processes – look for development in tech innovation.
• Leverage shared capabilities in logistics, and common processes