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.

As enterprise architects, we attempt to capture business strategy and put some alignment to our IT Strategy, and formulate an IT Current State and IT Target State architecture. The IT plan is the people, process and technology initiatives that we plan for the year, and potentially two or three threes out to move towards IT future State.

We have to have an understanding of the business strategies, priorities and external business environments to drive the overall strategic IT objectives. Analysis of the business changes and priroities drive the characteristics of the IT products and services, IT governance and the required IT capabilities.

IT Architecture is how we plan, and the basis for the efforts that we employ during the year to move closer to our goals. Definition of the technology, application and data architectures enable the IT strategy. Each must align with the business architecture, or functions and processes that we perform as an organization to sell or provide service to our customers. Effective IT planning is derived from tactically focusing on closing the gap between current state and target state.

The technology landscape is where my thoughts lie today. IT strategy is a business driven lifecycle, and it’s difficult to jump directly to the technology landscape when reviewing the linkage and relationships from the business. IT planning is an on-going event constantly refreshed to meet the shifting future state. It makes sense after we determine which data we need, and what solutions we will use to provide or manipulate that data. It is only after this point that we can determine which technologies we will use to deliver these solutions.

What if we consider the big jar and the stone philosophy? We have a large jar, and we fill it first with big stones, then smaller stones, then pebbles, sand and water to fill it. Our large stones in the area of technology architecture shouldn’t change often. Meaning – if we have an IBM mainframe solution, using a Nortel or Cisco network, and HPUX server farm, we’ve determined how we general want to continue to operate. Although we may have quite a mixture, we should generally know what our general direction is on the larger technology components each year – or which direction we intend to move as big changes are made.

These technologies will rarely have wholesale changes. Our technology landscape will generally stay the same, yet each year we must consider which larger and smaller scale changes should be made. There are none that should be made purely for sake of change itself, nor for the sake of “cool and new” technologies, unless innovation is our core business product.

In saying this, we as technology architects have the best chance of putting together our target state with the most certainty. Each solution and information requirement will cause us to change direction somewhat. We as technology architects should attempt to map how our technology components match to the business drivers in our strategic plans, but if this isn’t possible for us, or resides with our enterprise architects, it behooves us to have a very good understanding of the categories of technology components that we carry, the ones that should be slated for replacement, and those that should be enhanced.

Technology Landscape is most likely the most straight forward target state of the three domains. The minor stuff like lists of specific point software, appliances, etc. can be added as our needs are nailed down.

If technology architecture interests you, watch our seminars page at www.architectbootcamp.com for more information.

The place I spend many minutes were incredibly equipped to deal with the disaster. They have a DRP appropriate for their size and focus. We had PC’s to work on in another facility within 120 minutes. The PC’s were not equipped with the software which most of us needed, but we were able to spend some minutes doing something productive in most cases. Two departments were sent home, as there were only so many PC’s, and only so much spare space.

In contrast, there were vandals who were also disgruntled employees of a large tenant company in the same building in which I spend many minutes. They decided to use the fire hoses on the top floor and play games by filling the stair wells with water to express their discontent. Their employer decided to only pay them for a small portion of the day of pay they lost for that same electrical interruption. With only four weeks before Christmas, and being paid only marginal amounts over minimum wage, can you see the point of aggravation?

Now all companies affected must pay an insurance company to clean up their messes in offices that span the building, and the insurance company gets to collect several premiums because all tenants affected must pay, and the restoration company will pretend that they can do all of the work and make things right. And, next year and for the next five, all of these affected companies will get to pay some rich insurance companies extra premiums for bad experience.

Do I sound facicious here? I definitely am being so, as I have been the victim of water damage once and had to use that same restoration company. Believe me – you don’t ever want to encounter this so go right home and make sure you have the bullet-proof hoses on your washing machines, buy a water beetle and hook it up to your alarm system, and definitely ensure that the little birdies outside aren’t making nests in your bathroom vents so that vents are forced open and pipes may freeze.

Also – I am facicious because I have seen that tenant who employs the vandals exploit their staff, vendors and suppliers. If they would have coughed up the dough to pay a full days’ pay, or had a disaster recovery plan to enable the workers to do something else productive, none of that would have happened.

I continue my attitude as I had dinner with colleagues the day following the incident. We all shared work experiences and customer stories of the places in which we are spending many minutes. I found it humourous, then aggravating that one was spending two years of a client’s money creating a DRP and they still didn’t really get the point. Most companies who embark on DRP’s shouldn’t really call them that. They should call them their “how to get my technology all up and running”. Most have limited budgets and cannot begin to create a plan to recover everything. What about the business?

Why bother? Is everything that important? Is the little system that your company uses to catalogue the books in your IT library, or the research reports employees create when they really should be doing something else important? Yes – these things are great to have, if you actually had a reason for creating them, but is more than a back up really that important.

You knew I’d eventually get back to Architecture – I always do. I eat sleep and breathe the stuff. A great EA can completely replace the need for the kind of DRP these companies think they need. If your business functions are well (and I don’t mean completely) documented, and you know which ones you need to keep the $ rolling through the doors, and what their priorities are, why spend the equivalent of three or four peoples salaries in a year paying a consultant or two to write you a plan to recover everything you have as fast as you can? Believe me, some stuff can wait, and a backup of the data is likely sufficient.

If you need to get help on a DRP plan, I suggest you find someone who understands the concept well. If you want to completely document your technical architecture, good for you, but tying it to the recovery plan will only delay the process. The two should be separate endeavours and it should be pretty easy to figure out which one comes first. Key word is should.

There – the satiristical side of me. I promise to behave next time out – this was a tough week to feel productive.