The Architect Abstract

The Last Post

2008-08-11T11:35:00.002-05:00

Hello

This blog has now been moved

thanks - it's been fun!

Why are we here in the first place?

2008-03-03T12:46:00.002-06:00

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.

Happy Architecting!

SOA for the Technology Architect

2008-01-22T22:14:00.000-06:00

Hello from the eve of yet another EA Conference

Here I sit in Calgary, pondering some thoughts with respect to the topics at hand at tomorrow's EA Directions "Critical Issues In Enterprise Architecture and Strategic Alignment" two day conference. I have the great honour to present on several EA topics including some in the area of SOA. Last week, at one of my Architecture Boot Camps, the Technology Architect Boot Camp, I had another great experience with a very talented group of individuals from a very diverse set of enterprise experiences.

We discussed the role of the technical architect at length, and specifically that which pertained to services in an SOA and the TA's role. Two very distinct areas that I may not have paid enough attention, were consideration for the specific security concerns that are heightened with an SOA. I did not specifically high light this as a non-functional requirement, but likely should have. It is easy to rattle off the usual suspects such as availability, reliability, blah blah blah. But Security doesn't typically fall into this camp. It may be both functional and non-functional, and should likely be included in that checklist that we architects all peruse when thinking through those considerations that most don't.

Another point worth mentioning, is another complex issue surrounding SOA. After creating and designing the architecture for SOA, we need to ensure we've included an architecture that encapsulates the nature of monitoring, metrics, measurement and management of the operational aspects of the SOA-based services platform. I feel so strongly about these subjects, that I will soon release a special report on measuring such important details of the architecture environment, so come back and I'll be sure to share.

With both of these as critical factors in the SOA, it is very hard NOT to include the Technical Architect in both the design of the initial SOA infrastructure, infrastructure and platform, but should highlight the benefits of including such a role within your overlapped EA and SOA teams in order to ensure you have the right minds creating the best solution for your enterprise.

Happy Architecting,
Sharon

Technology Landscape - Your Best Target?

2007-10-02T15:41:00.000-05:00

In putting some efforts towards my fall seminar schedule, I have been focused on my technology architecture workshops and had a thought today worth sharing.

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.

Setting Your Scopes

2007-10-01T09:15:00.000-05:00

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.

I responded within the parameters of Enterprise Architecture at a company. EA provides IT governance and stewardship for any future technology planning and roadmap within a company or organization. An architect considers fundamental business drivers, structure of a system, it's components and relationships and then creates or tunes the best design to meet the needs of the business drivers and the organizational goals.

In most organizations, there are many systems that may cross boundaries, and many people in various roles with varying responsibilities that blur these lines. Evolution of one system to achieve a goal is often not achievable without understanding the relationship to other systems. This is the scope of Enterprise Architecture and the EA - he or she must know about the scope of all the systems and make the best decisions possible for the greater good of the organization.

The scope includes knowing how systems and their components interact, and their relationships to other systems and their components. Scope of EA includes the principles that govern the design and evolving life of all of the systems. The skill of the enterprise architect is in their abilities to see things conceptually, and be able to scale up or down, seeing bottom-up and top-down whenever they desire to take another view, and to keep this is mind when making key and fundamental decisions.

They require the understanding of it's relationship to all of the systems, needs, goals and desires of the organization. Making decisions without understanding this relationship is like designing a community in the desert without considering how air, rail and vehicle travel will reach it - the distance to the nearest power, water and electrical resources, and position on earth's topography for all such needs. Regard for infrastructure is critical, and the style of the community based on earth's disasters is the responsibility of such a planner.

These kinds of responsibilities like with the Enterprise Architect, so understanding the fit of the system to the organization is like the analogy of a town to earth's landscape and the planners who must create great places to live. The EA is also responsible for ensuring that growth of the town can happen naturally, without crisis and that effective living can occur when introducing new services that those who dwell here need them.

What is the same, and what has changed?

2007-09-27T01:54:00.001-05:00

Someone asked me a philosophical, yet, appropriate question the other day.

Why do I still continue to use a very simple framework in my coaching and consulting with Enterprise Architecture? I began using something called BAIT (business, application, information and technology), and turned to something else - BOAIT (business, organization, application, information and technology).

I thought for quite a while, and went through what has changed since I started working in the Enterprise Architecture space.

We went from application architecture, through system architecture (which now might be known as technical architecture). I saw Meta put forward a combined application and data layer called solution, and now we've hit the peak in the area of solution architecture (whereas no one really speaks of application architecture anymore).

Do we use Zachman, Dodaf, FEAF, or something else? It's all a matter of classification, and the purpose is communication. The clearest method has to be sufficient. The rest is background noise - it's about doing and using architecture, not just defining it.

My answer is simple. I started with a very excellent book that was very appropriate in the mid 90's. It is Steven Spewak's Enterprise Architecture book. At the end of the day, it all boils down to Applications (solutions if you may), Data and Technology. The business drives all of the other architectures, as they are wound within the strategic plans. None of that can really change - we can add SOA, Security Architecture, or change how we term what goes on in the operations and technical areas and we will still boil it down to all of this.

Our business strategy drives which data we need to collect, process and transmit. The systems/applications and solutions will provide mechanisms to make these transformations, and the technology in the areas of software, hardware, configuration, etc. will physically allow it to be so.

Nothing has really changed my perspective - just some of the details around how and why I would collect, analyze and interpret what I've categorized.

Architecture or System Requirement - What's the Difference?

2007-08-28T12:03:00.001-05:00

Lately, I've been working on the Architect Boot Camp info site and trying to lay out some really basic architecture information and some more advanced stuff. It dawned on me that there might be some who don't understand the difference between system requirements and architectural requirements. If this is news to you - stick with me. If not, I won't waste your time - catch you later.

Architecture requirements are typically those you collect during the initial scoping and context setting sessions at the beginning of a project while you are collecting high level system requirements. You need to determine the business objectives for the system, and for the architecture specifically.

It is so important to ensure that the architecture is aligned with the business drivers and objectives for the project. The architect keeps his or her eye on knowing where VALUE WILL BE ACHIEVED. What are the stakeholder goals? Main criteria for success?.

Setting system context helps to measure scope and set the appropriate boundaries. The architect needs to understand what the system interface will be, and what factors will characterize the architecture. Getting a list of top-level and high-priority goals will assist in setting this scope. This list can be further expanded when moving towards the elaboration phase of the project, and further gather the functional requirements.

The infrastructure must be designed to support the services and functionality that users require. It must deliver the appropriate levels of performance, security, usability and flexibility. All are factors that must be considered at the very beginning during the structure design and concept building of the solution architecture.

If the product is being purchased, the solution or system architects must review the requirements in order to determine their relevance and completeness. Specifically - those relating to non-functional requirements - specifically in the areas of performance, volume, methods of doing transactions or using the system, whom will use the system, how they will use it, etc. require review by the architects.

The architect must also ensure that these architectural requirements align with the Enterprise Architecture view. There are standards that are set for an organization, and typical infrastructures and patterns that are acceptable. Knowing, studying, analyzing these considerations in advance make up the architecture requirement gathering efforts for the early stages of the project.

These requirements need to be included in the solution architecture documentation set, and potentially used for volume, stress, and usuability testing during prototyping stages if the technologies are new, or if the requirements are risky.

Pure business functionality are user and system requirements. These are typically gathered by the systems and business analysts. An overview of such requirements should be held with the architect to ensure that they don't become intermingled, but there are shades of grey when it comes to "which documentation set" they belong to. You are a smart individual - you'll figure it out.

For more on architecture how-to's, visit The Architect Boot Camp.

Happy Architecting!

Decisions Decisions

2007-08-08T10:30:00.000-05:00

Long time, no type. I've been busy - but now have the time that this deserves.

I've just spend a near year acting as the Chief Architect at a large Canadian insurance company, and have many thoughts and insights I've love to share.

Here is one of the first.

Often, an architect, especially the chief architect, is asked to make an architectural decision. Typically, an IT resource is asking him or her to make the decision, but what needs to happen is the requester has legwork to do.

Typically, a high level assessment of what would be required to deploy the decision in the prospective environment is necessary. It is typically works done by their team, or by operations, or an application team.

The goal is to provide you with some key drivers you can use to make an informed decision. Although we would not perform a detailed assessment of the technology or solution, we would examine it at a high level the with the resources at hand.

The requester should then present this to the architecture team so they can make this architectural decision an informed one, and ensure the deployment on the platform of choice is valid.

In detail – the requester needs to do the following:

1) Assess and document the root problem being addressed.

2) Provide an overview of each option / alternative.

3) Give a Summary of evaluation criteria

4) Give a Comparison of each alternative relative to evaluation criteria.

5) List of "Implications" and "Impacts" of the recommended decision (assuming they have a recommendation).

Ideally, we'd like to reach a conclusion in the meeting together. Typically, questions that arise because resources are asking for a decision tend to raise a lot of questions when presented for the first time - leading to take-away work to gather specific information /research to feed a final downstream decision.

Time is usually in short supply, we'll attempt to work to the goal of a recommended decision within the meeting and the architecture team can provide guidance on the type of trials, prototypes and tests required in order for them to either raise this to the architecture review board, or make their decision.

Quick Wins in Enterprise Architecture - Part 1

2007-01-18T22:23:00.000-06:00

Happy New Year! It's nice to be back again and writing about my favorite topic.

This spring I'm speaking at the Enterprise Architectures Conference on Quick Wins in Enterprise Architecture so I thought I'd share a bit of the content.

Enterprise Architecture as a new program within a company or an organization is difficult to kick off. Often there are so many things that need to get done, that we are overwhelmed. We might resort to following recommendations or readings we might find in a book on EA, or from a paper, or even a framework.

Many newbies will get a framework and attempt to start filling in the cells. Others might pick up Spewak's book, or some other writing and start with a pure planning method in which we capture Goals, Drivers, Strategic Direction and then Current and Target state with hopes that it will eventually turn into a migration plan and eventually projects and a set of standards and principles.

If you make a quick list (take no more than a hour to do this) of the things that you would like to include in your plan and then EA projects that are most needed at your organization. In speaking with my CIO today, he said that a list of what we had depicted graphically with a target state mapping and then a status for each technology with respect to "contain, expand, conclude" or other such terminology to state plans for their use going forward. Even in a very large organization this is relatively attainable unless you are very distributed.

It is perfectly acceptable to have multiple technologies within a domain. For example, you might designate one database technology for small and medium applications, and another for large enterprise applications or solution specific applications where there is none or little choice.

Statements as to whether or not you will acdept or embrace open source, and the types of platforms that are suitable for technology "families" or categories of activities to be performed on one particular type of service (Unix flavoured or Intel for example), is also very helpful. General guidelines will help teams when they are searching for solutions.

Well - this is just a hint of what will be included in my topics and further writings.

Happy Architecting!

2006-11-06T17:19:00.000-06:00

Cooks in the Kitchen

2006-11-06T17:05:00.000-06:00

Does it ever seem that as an Enterprise Architect, we have many dragons to slay? Our organizations confuse the Chief Architect with chief technology problem solver, and it isn't their fault. Often the current technology hot spot of the day is something that lives in the EA realm, and we are the captain of the ship.

We've had many metaphors - the Builder, the Architect of a house, the City Planner, or perhaps the Pilot of an airplane or ship (thanks Mr. Zachman!). Here is mine:

An organization, when embarking on an EA program, needs a cook. They need to mix some things up to create a tantalizing dish. There is not often one recipe, but several that might suit the ingredients you have at hand. At some point, depending on the size of the organization, you may find that there are too many cooks in the kitchen, and a chef de maison, or Head Chef is required. The chef will prepare the menu, and ensure that the restaurant has the ingredients at hand.

What the cooks do to add flavor and seasoning may be their choice, or it may be strictly regulated. The McDonalds restaurant does much to ensure that their food tastes the same each and every time. Some restaurants to do - these are not chains, but individual "spots" for a bite out.

Sometimes, there are too many cooks in the kitchen. As of late, I've seen several folks try their hand at mixing and matching SDLC's. The chief architect may or not get involved from a standards perspective, or from a governance and compliance issue with respect to artifacts. There is no "right" SDLC. The facts are simple - too many cooks will ruin the soup - too many flavors will confuse the issue.

One recipe may be selected for the best "dish of the house". There is room to decide whether the head chef is creating the meal depending on the appetite. If there is appetite for chateau briande, so be it. The SDLC will be complex with many options. If there is only appetite for deli or fast food, or perhaps even the corner restaurant that sells burgers and fries, the SDLC must be simple with few key artifacts and simple methods.

Chefs - the choice is yours. Remember, if there are too many cooks in the kitchen, there will be a fire!

Happy Architecting.

Governance - Abusing the Buzz Word

2006-10-02T22:04:00.000-05:00

Well - it's been far too long since I wrote - but I am committed to writing more. I've just been exposed to "governance Overload". What is it you say?

Well - after a weekend in Boston and time with the ultimate of buzz word abusers (this generic professional group shall remain nameless), I'm sick of "get it done", "dropping the ball", etc. etc.

Instead - I come home to a day on my new gig and abuse of the word governance. This blog has turned into a bit of a rant against the abusers of IT architecture and now it's time to spout off against those who can't find their way into a wikopedia entry.

Architecture Governance is different that IT Governance. IT Governance is NOT, and I repeat NOT project prioritization. It might include it, but it is not it. IT Governance includes the process around IT decision making, adhering to standards, patterns and process guidelines. Architecture Governance is the process around governing adhering to Architecture frameworks, guidelines, principles and standards and the methods to make your way around them.

Why does this matter? Confusion about terms such as governance is rampant and since people like to exchange the word "architecture" for the term "diagram", it deserves more references here. Governance is about the process of systematically and orderly controlling the process around decisions. In this case architecture or IT governance. In my case, Architecture governance allows those who wish to sway from the norm to get a say and have a chance at doing something that is right, but isn't necessarily status quo.

Today I sat through a meeting requiring an architectural decision. For a change, I am in a position of both authority and influence and got to be the governing panel. I listened to those who wanted to argue their case for option B when option A was status quo. After all was said and done I couldn't choose either. Both were silly and didn't make security, architecture, nor financial sense. It was option C that won out. See - what a great example of how architecture reviews make sense and are worth the effort. No one came expecting option C to be chosen even though they were afraid to choose it.

Option A was status quo and everyone geared up for option B. By bringing it to my attention, raising it to the top of my radar screen, option C was up for consideration and it won. See - there is a point. There is democratic decision and discussion. Architecture review boards, their process and methods are worth the time and efforts attributed to them.

that's my thoughts for tonight - hopefully I'll be able to share more another day - this was fun!

Sharon

Business In the Driver's Seat

2006-08-10T16:47:00.000-05:00

“By 2008, 40% of enterprise architects will have primary expertise in business strategy or process engineering” 2004 Meta Group, Inc.

They get it. Businesses appreciate, accept and now accentuate the role of the architect in their organizations. It took some time, but they get it now. I might generalize and say that most medium size businesses have some sort of architecture function in their midst. I’d go further an say every large business now believes that architecture is the brass ring as far as IT success is concerned.

The business drives the business, and now we, as IT practitioners get it. We are finally focusing on things like Project Management, Business Analysis, Business Process Reengineering, Portfolio Management and aaahhh, yes. Enterprise Architecture. EA starts with the business strategy, and the great architect will become verse in business strategy. Our business strategy.

For more details on these thoughts, check out my information site and an article entitled "Business In the Driver's Seat"

The Architect and the Merger & Acquisition

2006-08-10T16:46:00.000-05:00

Mergers & acquisitions – Calling All Architect’s – We’ve Got a Merger & Acquisition

What are your IT Project Priorities – do you have one of those "Yours, Mine & Ours" situations???

What I mean is that when a business decides to buy another company, or merge with one, often there are multiple perspectives to project priorities. If one business arm decides they need a bigger sales force, and another wants to gain proficiencies in a manufacturing process, there may be conflicts. Add the fact that the IT area wants to streamline, yet add or upgrade technology infrastructure, we're cooking up a recipe for missed expectations.

The IT Architect needs to understand what the end goals are by the business when creating the architecture. If you want to read more on ensuring you understand the right messages and goals, why don't you check out my information site - Mergers & Acquisitions and the Information Architect is an article that addresses this topic.

It's a sample exerpt from our eZine "The Architect Abstract". Head to the site to sign up to get a copy every week, or view the sample articles to whet your appetite.

Happy Architecting!
Sharon

Information Architecture Gets Super-Sized

2006-05-30T21:00:00.000-05:00

Hello,

Long time no type -I've been really busy writing content for my latest courses and this came up during research. Each month I play a game - search Google for the keywords "Information Architecture" and see how many bogus links you find before you get to the real stuff. Today I only got to this Maskery Tom Foolery before I had to stop and write something.

The sad thing is that I don't know the answer to my question - how many pages does it take before one searching for information architecture can get to the real stuff? Last month, it took 19 pages of Google links before I found something that even resembled information architecture.

Why do I call the fluff not so real? There are so many folks eager to super-size IT, IT Roles and borrow or steal the work architecture to make their products look a little more saleable, and specifically those working in pure web site development and content management are the villains here.

I've said it before, but I'll say it again - Information Architecture INCLUDES content management and web page/site structure design. It is not Information Architecture. IA is all that surrounds the information domain within the system or enterprise architecture. It includes servers and software that house the databases, their structures and operational systems. It includes the many types of data and database models, as well as the repositories, scripts and dictionaries used to describe the data and content stored. It CAN include content management software and the infrastructure required to run it.

This page I've referred to above states the following: Below is a schematic of an information architecture

NO - this is not a schematic of an information architecture. It is purely a website navigational map, or as VISIO terms it, a WEB SITE MAP. It is not the architecture - do you see any diagrammatical objects that depict where the information is to be stored, how it is to be stored, and in which technical manner? Do you see any models of the data, or conceptual intent? Do you see any relationships between the data.

Sadly enough, there are hundreds, if not thousands, of companies slogging this marketing type with their product. Super-Size is a McDonalds term, and I'm using it here to refer to the act of making something seem large just to sell more, without much more than added calories. If you want to see more of what this stuff is really made of, see my Information Architecture page.

Connect the Dots - EA and Portfolio Management

2006-05-04T23:20:00.000-05:00

Ok - so maybe you haven't heard the buzz about the marriage between EA and Portfolio Management. It's been going on long enough to get the seven year itch already - so why should I go on about that today?

My head hurts - I've been knee deep in the weeds building courseware for about three months and I've come up for air. It's probably the first thing I thought of because I was digging up some articles for a participant in a workshop that was in need of more info on the topic. Or maybe it was because I was drawing diagrams all night and when I was done I couldn't remember if the diagram was going into an article for a Project Management piece on Portfolio Management or an Enterprise Architecture.

To make a long story short - they are the same Portfolio Management. Different constituencies might care for different reasons, but at the end of the day, the same portfolio should be planned. Granted - if the Enterprise Architect gets their way - there will be the project completed that gives him or her the best new models to add to their collection - isn't that what everyone thinks we do? Or is it picking the standards that everyone has to follow????

Actually - it will fill a gap from the charts on the analysis task of the most recent EA program review. And - it will match up to the latest and greatest business initiatives sadly lacking archtitecture. What difference does it make? The EA's and PM's need to work together, and other than a few squabbles about scope - aren't they fighting the same battles? To get sorely needed projects done with precious few budget dollars?

Another thought on the subject - the project manager and the program or portfolio manager are fighting different battles. The project manager wants to get the project done as directed, with as little risk and variance on budget as possible, with the best use of resources as possible.

The EA wants to get the right things done, and usually budget is the last thing on their list, other than the fact that they don't want their EA program shut down. So - we'll all have to get along here. We want to do the right things, ones in the best proportion to keeping the business running, getting the optimal amount of growth in the organization, and transforming that organization to meet strategic needs of the executives and planners.

At the final outcome, both parties will be happy if they solved a business requirement, met an organizational objective and ok, created a few models along the way. Is that so bad?

Happy Architecting,
Sharon

WHAT IS AN ARCHITECTURE FRAMEWORK?

2006-04-03T23:15:00.000-05:00

One of the most ambiguous words in the initial understanding of Information Architecture is that of the Framework. The Framework is a generic categorization method for architecture design artifacts. Any good categorization method achieves these EA goals:

1. Simplify information for understanding and communication
2. Clearly focus on independent components for analytical purposes
3. Provide and maintain a disciplined method of depicting relationshipsbetween the domains.

A Framework is a set of approaches, components, configurations,models, services, standards and principles that can guide you in your documentation adventure of a particular view of an architecture.

HOW CAN I BENEFIT BY USING A FRAMEWORK TO GUIDE DESIGN?

While there are many benefits in using a framework to guide your development efforts of an architecture, there are two that are moreelementary and prevalent than others: Guidance and Communication.

The framework is a guidance tool which is used to ensure that each architecture domain is adequately reviewed and documented, and canmost easily be compared in context to the other domains or views. It guides both the method and approach to completing an architecture,and enables all stakeholders to see a consistent and complete picture when reviewing an architecture.

The framework can be used as the primary communication vehicle between architects, the project team, stakeholders and IT technical staff. It can be used to show what you've planned, and how you will achieve flexibility in the future.

Other benefits that you may expect from using a framework, is the provision of a generic space and structure for a very complex and varying problem. It can include a starter set of principles, issues and concerns. It can provide guidance on which sets of diagrams and models to include.
Think of it as a "placeholders" map to what would make a complete architecture. It is also known as a set of views of an organization and its Business and IT Resources and assets.

WHAT FRAMEWORK CHOICES ARE AVAILABLE?

There are numerous frameworks available to be used, but they are primarily categorized by domain. They are typically designed for government, or non-government (private organization). Some are strategically oriented and some are focused on organizing the evolution of the architecture.

An organization can choose to adopt an existing architecture framework or to build a custom framework. In either case, it is rarely necessary to start from scratch, and the primary focus should be on the stakeholders and the domains you wish to capture. Try to keep in mind that the primary goal here, is 'Communicate that architecture!'

If you choose to adopt an architecture, consider visualizing what kind ofdata and models you will use to populate it. Ask yourself 'what is important to my organization?', and 'how have we organized our departments and business in the past?' Many frameworks are used for a particular type of community, so try to pick the one that is most similar to yours.

Enquire with peer organizations as to which type of framework they have used. There is value in understanding and using more than one, so pick the one that is the closest, and adapt it by selecting one or more components you would need to close the gaps between the one you select and what you need for your organization.

If you choose to build one, please consider finding one or two that have components of what you need and take pieces to build your own. We really don't need to reinvent the wheel. I prefer the 'a la carte' method myself, and have actually trimmed one of the most simple and straight-forward frameworks available, then customized the look, feel and tools as well as the processes for it. Customize it to suit your culture and technical vocabularies for the ultimate in success!

WHAT FOLLOWS YOUR FRAMEWORK CHOICE?

Today's newsletter won't attempt to describe the Enterprise ArchitectureProcess, nor the strategy to complete it. What I can do is give you a few hints about your next move after choice. I have spent a great deal of time and effort studying and customizing decision making techniquesfor my consulting engagements, and one of my secret weapons is the'litmus test'.

After a framework has been selected, evaluate it's use within your business environment. Review the goals and objectives in using such a framework, and see if what you picked will work. After treading througha few examples, list the lessons you may have learned and refine whatyou've selected.

So there you have it - my quick thoughts on Frameworks. I have many more, but these are the basics that I might write about without much effort.

The Crystal Ball

2006-03-21T07:04:00.000-06:00

Do You Have a Crystal Ball: 3 Future State Architecture Keys to Make them Think So!

Documenting the current state architecture is a must to any enterprise or system architecture report, and even though we understand this, it’s the future state that everyone is anxious to see and share. Let’s face it – they are also waiting to critique it. There are components of a future architecture that make or break its impending success – or failure. It seems that there are three surefire keys that you can include to ensure success!

Let’s suppose you are responsible for the System Architecture or Solution Architecture for a new custom application in your enterprise. What mandatory items should your checklist include when documenting the future architecture?

1) Strategic Direction

Opportunity creation can be achieved by analyzing relationships between Strategic Drivers and Business Architecture Components. Those who need to buy into your future state architecture need to be able to visualize the opportunities, and taste those benefits! The business architecture should include these items to articulate strategic direction:

List and adequately describe the Strategic Drivers behind the architecture. If there are many to be listed, separate them into “Primary” and “Secondary” or some other tiered scheme.
What new opportunities will be addressed by the new system?
What potential future opportunities are on the horizon can be accommodated by the future state architecture (read flexibility!)

2) Justification should be the key focus in the System Architecture (Application & Information). You will gather information for justification of system enhancements while analyzing the relationships between the Strategic Drivers and the System Architectures

Define what kinds of application systems will be relevant to the enterprise (based on strategic drivers)
Describe the application as logical groups of capabilities that manage the information (capabilities that match to the strategic drivers)
Describe the methods that support the business functions described in the Business Architecture (Linkage)

Include these items in terms of both the Application and Information, and you will have justified the new system.

3) Automation Efficiency should be the key focus in the Technology Architecture. Benefits can be collected when analyzing relationships between Strategic Drivers and Technology Architecture

Describe future standards and technology principles required to support the new system (based on the strategic drivers)
Describe the technology platform required for the new system
Describe the anticipated distribution of data and applications

If you are able to create a visual presentation for your audience, include these three main points on your agenda – tell them that you will prove that your future state architecture provides alignment with strategic direction, added capabilities to enable business drivers, as well as automation efficiency using technology, and I’m sure that you will definitely have an interested audience!

For up to date information on IT Architecture, visit www.architectbootcamp.com.

Happy Architecting

Sharon

The IT Profession - Are We Ethical?

2006-02-21T21:51:00.000-06:00

Hello - long time no chat.

I've been away building and authoring courses, so writing has gone into something other than frivolous blurbs. Just came back from an evening with a speaker on ethics - it was supposed to have something to do with Ethics in IT and although that's not what it was about, I was able to draw a few lines and relationships to IT from what the speaker had to say.

A few thoughts that came to me through this - there was someone who asked how it was related to Risk Management. It came from a security professional who was also a Security Consulting firm owner. In a way, it seems that about half of the questions posed in one of these sessions are self-serving, and this seemed to be one of them. The speaker gracefully told yet another anecdote - the speaker seemed to have nothing but, but we heard about the Pinto story. The company weighed their options, and chose the least expensive, without looking at the risk or harm to the ones that would be blown up.

The speaker also told anecdotes about butterfly ballots and the loss of trust and believe in politicians. I'm not sure this has changed over time, but rather has just become more exposed because of IT and the world of information. Scandals are instantly publicized and we can find out both the truth and rumours almost moments after they happen.

The speaker specialized in Biometrics & Ethics and stated that they didn't trust the medical system or doctors. This came from the whole whistleblower issues and the lack of benefits to those who do expose those who stretch, bend and manipulate the better good of society for medical profits. Doctors and hospitals take money for research, funding and sponsorship in exchange for the promotion of a pharmaceuticals drugs. Researchers are encouraged to hide data that might be detrimental to the unveiling of a prospective lucrative drug.

How does any of this relate to IT? The speaker did mention IT a couple of brief times - both times resonating something within me. His first comment was that we are now able to get a lot of data cheap, which is causing trouble in this world. Examples were getting enough data to steal people's credit cards, get enough information to impersonate, and also to spread viruses and cause billions of dollars worth of damage. He alluded to the fact that we are able to get information fast which might be helpful. No anecdotes - this might have been about fear and his anecdotes about the bad were better than the good.

How about being able to send email to those we like and love that have moved away, or sending notes back home when we are forced to be away. How about getting information from legal sites on companies that we are about to do business with and expose the frauds they are before they happen? How about researching tools and items for purchase in a preliminary way, bettering our decision making processes, or arming ourselves with background information so that we might ask better questions in order to get better results. Our infrastructure designs have become so complicated and we have so many choices - we NEED to get information quickly.

The second thought I had during all of this, was that if we are to be ethical, we must balance our need to make a living and a profit in doing the right thing. We as architects must weigh our inherent desire to design the best architecture with one that is good enough for the time and budget allotted. Professionals such as engineers, architects, doctors and accountants take oaths that they may or may not be able to recite a few years past their indoctrination, but most will not sign or do things they know will jeopardize their licenses.

We don't have licenses, not yet anyways, that we can use as our backstops and reasoning against doing the wrong things. All we have is our pride and reputation. We can use our talent and skill to do the right thing and pick the best architecture or make the best architectural choices that fit our PM's budget, time and quality requirements. We have to protect our reputations, and sometimes we have to walk away from the project, contract or decisions that we feel are not right, even though we are feeling intense pressure to do otherwise.

What a Disaster!

2005-12-02T08:40:00.000-06:00

This week was interesting. The place at which I spend many minutes had a disaster. There was an explosion below the street, causing one unfortunate soul incredible burns, and an entire block the loss of power. Some residents nearby were without heat for over twenty four hours. That's not good if you live in a winterious place.

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.

A Journey to the High Road

2005-11-17T17:19:00.000-06:00

I’ve been asked over and over how I became an I.T. Architect. I always hesitate, and say “well…” More often than not, I get into the long stories about my university degrees and my varying path in life and career. The short answer is “I changed careers multiple times within the field of I.T.”. The long answer is experience.

The I.T. Architect is a technologist, a leader, a consultant, a strategist, a politician, a writer and an artist. Yes, I threw that last one in for humor, but I get countless “way to go Picasso” comments, when I’ve helped a client with a modeling conundrum, or even cleaned up after a whiteboard session and converted our thoughts into something readable, tangible and electronic.

As a technologist, the architect must specialize in technology, information or applications if he or she is a domain architect “Data Architect, Information Architect, Technical Architect, Application Architect, Software Architect, etc.” I must understand the pertinent technologies, plus have an in-depth understanding of the entire domain. Learning the key issues around my domain and knowing the Best Practices and key standards, methods, processes and techniques key to being a good practitioner is also necessary.

I consider all the matters at hand, and analyze the tradeoffs. I get to “play” by prototyping and experimenting with technologies, taking various system viewpoints when drawing up models and then testing them later with prototyping tools. I am fortunate enough to keep tabs on the “what’s new” in technology, and follow the trends and create roadmaps for the future. Mapping out where you want to go is always done in a more positive light than where you have been.

As a not such an enjoyable task, the Architect must document and present their findings to incredibly critical groups of people. Everyone has an opinion, and at the end of the day, even with a little bickering and bantering, it’s all a good thing. I’ll take that over dead silence any day. I get to do the investigations, and create the future, so I must be tolerant of changing my work on an ongoing basis to accommodate the opinions of many, while maintaining my initial vision.

Strange But True

2005-10-31T20:46:00.000-06:00

Boo!

Did you survive the EAC? I am almost caught up on my sleep - just a two hour time change plus flight plus daylight savings time and I've turned into Rip Van Winkle. I'm sure I'll be caught up by tomorrow, but still have lots of miscellaneous thoughts swirling around in this head.

About 18 months ago, I gave a presentation at a Canadian Information Processing Conference, titled "Enterprise Architecture - What Have You Done for me Lately?" It was all about Enterprise Architecture Maturity, and convincing folks that EA was far more that hanging up the Framework and letting the holes and gaps emit light.

This past week, I heard so many points over again that I'd made myself and I wondered how this was possible. I guess it's just that this stuff makes sense to those who live and breathe it and there are just so many ways to say it. This week I heard all about the "value in the arrows", or perhaps that's how I perceived it as it was a scribble I'd noted in the presentater's note copy that I returned with.

My speech on EA maturity was about adding the linkages as that was where the value was. I guess this is essentially the same. It's about creating the relationships to add Architecture value. Listing all of the components, technology and hardware only has so much value. It's when you start to measure it and create the numerous amounts of relationships that you see value.

Something else, strange but true, but I noticed that three of the six panelists on the "Ask the Experts" session on the last day were Architect's who were former Data Architects, or had written columns in data magazines I'd followed in the 90's. Well - that's where my roots are and I wondered if all Information Architect's had evolved into EA's. I mean - we were the only ones religious about models in the 80's and 90's, so it probably makes sense now, doesn't it? Boxes and arrows, lines and boxes - whatever it takes to provide value - it's the way we think and there is no changing that.

My last "Strange but true" thought for this Hallowe'en night - thought it was odd how this year's new comment addition to John Zachman's otherwise similar message was that he'd had a complaint about his slides by the conference coordinator. Apparently he'd pointed out to her that he had to continue to return with the same old slides because he had the same old thing to say, and that no one listened to him anyways.

Now - how can one person run around for thirty years trying to get everyone to listen and to follow. Mr. Zachman obviously is tenacious, as he has never given up because he believed. And by the numbers and passion I saw around this subject at this conference, I believe that he will soon be able to retire a very satisfied person.

Well - enough blogging for now. Time to hide the leftover candy and put away the pumpkin.

Boo!

The Games Continue

2005-10-27T23:26:00.000-05:00

Here I am again, bleary eyes but wanting to share all from this year's Fall EAC. I have so much to share, and tonight will just have to be a summary. I catch the red eye in 6 hours, and suitcases still have to be filled - you know the drill.

This year was a little different. More keynotes, but fewer messages. The last one was fabulous, so all is not lost. John Zachman has finally admitted there is no silver bullet and still maintains that one day we will all wish we'd filled his magic framework. I'm not arguing but there were more that agreed with me this year that feel practicality is a virtue.

The conference offered two panel sessions this year, and not as a keynote. Great touch - heard some great things except for a 30 minute drone about certifying EA's. There is much passion about this, but hard to get excited after listening to it around the CIPS ISP. Sort of boring and so far from reality. Perhaps we should work on a common vocabulary as I hear more acronyms that you can imagine for what goes on in the Business Architecture. Reminds me of the early nineties when modeling tools first entered the scene and with a flick of a button you could create a new flavour of the day - all of which equated to a logical or process flow diagram.

There was an increase in both the sessions and numbers of folks who attended the "Build" as well as "Run" Sessions. Good for you! This just means that there are the masses attending the Plan, meaning we still don't have anything done yet.

The most common question I heard all week was "how do we know when we've modelle enough?". Various answers - deserves a blog onto it's own - but all it means is that we're progressing.

Well - have to type more tomorrow - 4 bells come early and I will take a break from this little stanza.

Happy Architecting and Happy Friday!
Sharon

Let the Games Begin

2005-10-25T00:01:00.000-05:00

This week will be special - I get to spend a week with other architects at the DCI Enterprise Architecture Conference. Ok - I'm weird - I love to talk about this stuff, but this is like sending a Gambling Addict to a Casino - oh wait -that's where I am!

Never mind - I tried those slot machines and any way you slice it - you will lose. Bet the farm on EA and you will win. It's exciting - I get to talk to some of the smartest people around about the coolest projects, and learn at the same time. Today was just the "opener" - a new CD to peruse, and some sessions to pick from, as well as a vendor presentation.

Now - I might be biased, but no matter how many vendor presentations you attend, you have to agree - there are some gems of info amongst them. Today I listed to Telelogics's presentation on what they have to offer the Architecture Tools space. Always interesting, as the EA's that I know are incredibly demanding and always want one more thing that no tool does. This was an interesting approach - buy the pieces you need to fill your gaps, intelligently - like an EA would do it themselves.

Now - don't get me wrong - I'm not condoning their tools - if you know me - I don't do that. But I like to see the good or best of breed where credit is due, and it looks like they've approached it in another manner. I'll be interested in visiting the vendor fairs tomorrow to see if I can see at a glance where the rubber meets the road.

If not, I'll definitely tell you to save your money. If we're lucky - it'll make the hopeful list and give us Architects a chance to automate some of our work.

Until tomorrow

Sharon

The Main Issue with Enterprise Architecture

2005-10-16T09:46:00.000-05:00

I spend time weekly trying to think of "shareable" things I've done I can put up on the www.architectbootcamp.com to spread the wealth in creating more and better I.T. Architects.

I sat down the other day with a napkin and a pen, trying to list all of the issues I've heard clients mention or express concern about and thought these would be ideal subjects for blogs or newsletters.

Issue Number 1 - Getting Enterprise Architecture Funded.

If you have Mr. Sarbanes, or Mr. Oxley knocking on the door - you have already danced this dance. Executives fully understand the value of architecture, and you've likely got a good head start on a program and maybe even a plan.

If you were to say to a CEO "If you don't fund this project, it tells me you are not really serious about this business strategy" what do you think you'd get back in response?

If every time you were handed a new business initiative to "implement" - I mean - make all I.T. modifications or additions to support it, wouldn't it be great if the CEO also had budgeted a step for "update Enterprise Architecture and align I.T. with this strategy". Ok - so many of you are now leaving saying - yeah, right.

But what if you could prove to the executive, or demonstrate to them that each time they come to you asking for a strategy to be "IT-ized", the planning and development of it could be on a gradually reducing time line if you had architecture in place? Now we're talking. It's so hard, and you continually have to prove value. These are the reasons that EA is hard to justify - it takes doing it and proving it to show value, and you can't really do it or prove it until you've done it.

Not quite entirely true - you do components or pieces of it all of the time, usually by means of projects. What if you were to document the wins from those projects, and tie them to a framework, or lite view of framework to show you've been working on this all along. You might have a conversation to get this rolling about the possible benefits. An extra win might be in order if you happen to mention some of those times that the Executive was happen with I.T. results and demonstrate the Architecture components or efforts.

Happy Architecting,
Sharon

Just How Many Ways are there to do things?

2005-10-06T19:50:00.000-05:00

I'm sure as many of you do, you reach home after a weary four days of work and are frustrated because your work seems to be one big giant conflict. You spend an hour and a half of a one hour meeting (notice that we only went over by 50%?) going back and forth and back and forth. You might get a turn with the magic white board markers, confident that once you play picasso, everyone will get it and the argument will be over.

Well - was I in a doozy today - I just sat and played the referee, as it was the role I was paid to play - I would ask questions like "What if you were to ..." and see what they'd say. At the end of the day, I took on another role - it was to say - something like "let's say there are two options - which would you prefer?"

Now we're getting somewhere - people are always better at pointing out fault with something concrete, rather than trying to come up with pieces of something or arguing about minute points.

If you get to play architect, this might be one tactful approach. Architecture is more about politics than it seems to be about technology. You can't just show up as a great IT polician and expect to be a good architect, but if you are a good architect, being tactful and a great politician sure helps.

So back to the dilemma at hand. Do you ever notice that at the end of one of these types of meetings you are down to two options? It's not that there are just two choices, but there are two that the group hasn't discarded and are willing to back. Pick one, see if it looks like swiss cheese, and then jump ship if it seems that it won't float your boat!

The Architect Abstract

2005-09-26T19:02:00.000-05:00

What came first – the solution or the data?

I’ve spent years in IT and no matter what I do, it keeps coming down to the data. As an Enterprise Architect, selecting a portal for a large financial company was an exercise to plan for technology that would support data in many areas.

As the years go by, Data Architects have become responsible for Web Site Content. Sadly, there are many folks out there on the Web who actually think this is Information Architect – yikes. (see my related article at Architect Boot Camp in the Information Architecture Section It is so much more than just content, although the Data Architect’s job has become so big when they have to figure out how this stuff is going to be stored and organized as well as designing custom databases for inhouse applications.

So when you are called upon to create a Solution Architecture – where do you start? The requirements is usually the first place, but often the requirements come out in the form of Data. Someone says “we have this sales information and we need to make it viewable and include the ability to create custom reports for our marketing managers.” So what do you do first? Do you create a data model? Do you pick technology to run it on? Do you choose the application technology you will use to create it?

Architecture is both a means of doing an inventory, linking and creating new stuff. The inventory in this case includes finding out if this data all lives in a database you can access directly, or whether or not you need to create a new one. It also includes an inventory check of the custom development and data warehousing technologies you have, as well as the interface technologies you have to bring them to the users.

What about security? Do you have that in place to present this information to the marketing team over the net in distant places? Or do you need to protect this stuff so Walmart can’t get it (just kidding – they are the favorite commercial villain, right next to Microsoft!).

How about resources – do you have anyone in your company who has done this before? Can you borrow someone who’s done it, or better yet, some application and resource who have done it and simply tweak it to get new data?

The longer you’ve been around as an IT Architect, the better you’ll get at recognizing patterns, inventorying them and picking them back up and dusting them off for a new solution. Ain’t life great? The best employees might also be the ones who try to do as little new work as possible!

First Blog

2005-09-19T12:15:00.000-05:00

Welcome to the Architect Abstract Blog Edition 1

The Start of ASolution - is it Data Architecture first?

Today I'm thinking about how important data design really is to solution design. I often wonder if our roots in Information Technology will always take over our thoughts - I used to work exclusively with data and moved on to Architecture. Now, when I work in the System Architecture space, particularly on design or solution, I revert to data - and often first.

We need to understand what the data will look like and what is needed before we can design. After all - information technology is about information and always about moving it around. We manipulate, massage, analyze and display it - what impact does it have?

Today I am trying to help clients come up with a new way to allocate files based on a bunch of business parameters. Over the years, they have bandaided the process, and morphed it based on many business needs that have nothing to do with the allocation itself. It was almost mind numbing to walk through the paths and rules that had been added over the years. I'd get
frustrated and start over and over going back through the data.

Eventually I thought "this is crazy - what are we really trying to do here, and what is the bare minimum of information we need?". Simplifying things brought clarity. After I weeded out all of the special cases, I found that the solution was rather simple - there were two basic methods, with a third method that could be applied to one of the first two based on a third parameter. Voila - done. Add a bit of history logging to enable lots of great reports on performance, volumes, etc and we have a great solution that everyone understands.

There - that's it - my first thought of the day - this is going to be addictive to be able to organize all of these Architecture thoughts in short bits, as I have them.