If you ask just about any IT Director, Manager, or even PM, they’ll tell you that Architects are amongst the toughest resources to find.  I’ve experienced this so often either when helping clients build their teams, or when I’ve tried to build them myself.

Architect Boot Camp training was designed to help organizations train their own staff, or to help those in IT who have an affinity towards high end design & IT Strategy, but want to hone or learn Architect Methods, Process and Approach.  The objective is to deliver the theory, while using real life scenarios and then practice through case studies and exercises.

This fall our IT Architect Boot Camp workshop is now full, and we have but one spot left in our Solution Architect Workshop.  We had to move to larger space to deliver the workshops, and I’m sure with the great mix of staff and experience, they’ll be a good experience for all attendees.

If we can’t find architects, we’ve got to grow our own.  We need to optimize our IT dollars, and now more than ever we need to make sure we’re building and designing the right things.  Just ask John Zachman - he’ll tell you that Architecture is the ONLY way we can improve our success rate.  Only three days to go until the start of this first public offering this fall, so this blog entry will have to be short.

By the beginning of November, there will be several more architects ready to provide value to their organizations.  We must applaud organizations who believe that investments in their people are good ones, and won’t be impacted by rough economic times.

Happy Architecting

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!

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.

Want to learn more about frameworks?  See our member site.

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

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.

Happy Architecting!