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

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

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

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

Architect Abstract Ask Contest

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

Happy Architecting!

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

What’s new?  I’ve been really busy getting the fall 2008-09 Architect Boot Camp Workshop schedule completed, as well as some drafts on my book and the course ware updated.  I’ve gone with a new set of lab exercises, as well as a lot of more up to date content.  After a recent speech at the Open Group Enterprise Architecture Conference, in Chicago in July, I felt that a more expansive section on TOGAF was warranted.

As well, the Firefli Web Site has been updated with a new blog format, so that I have a hope (and a prayer) of keeping these things up to date!

Upcoming events are detailed on both the Architect Boot Camp site, as well as Firefli.  I will be giving a speech “Good To Great – Paving the Road to Excellence for the Enterprise Architect”at the upcoming Enterprise Architecture Conference, provided by IIR.  More details as they are posted on their site.

Happy Architecting!

Sharon

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!

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

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.

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.

Happy Architecting!