In putting some efforts towards my fall seminar schedule, I have been focused on my technical 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.

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 Read the rest…

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 Read the rest…

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 Read the rest…

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, Read the rest…

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 Read the rest…

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!

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 Read the rest…