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

Recently I was asked that if a person was already acting in the role of a software integrator, did they really need to learn how to be an Architect.  The answer was a little bit complicated, but it was an emphatic “yes!”

While the basis or core skills of a great IT architect does come from solid software integration knowledge and practice, the basic practices, approaches and thought processes as well as ways of thinking in the correct context is what is taught during an IT Architecture workshop.  Various approaches and ways of thinking allows an IT Architect to get a new perspective of the various contexts they must review before choosing a solution or constructing an architecture.

There are various thoughts on how one becomes an IT Architect, and granted there are so many ways to get here, the result is the same.  In order to become good or even excellent, the Architect takes on a different mind set.  There are various perspectives that are reviewed, and as well, various options with respect to ways about thinking about the issue, problem or opportunity are reviewed.

The architect considers more than fitting two pieces of software together, and the approach learned in a workshop will take them through the business objectives and IT Enterprise objectives, through to the various decision making techniques and options for formulating a solution.  Typically the instructions given to an integrator are taken after an architect has determined the best approach and seen best fit for the components that are selected.

During these exercises, the architect takes on a different approach with respect to requirements analysis, solution review, as well as some softer skills to deal with the political and communication parts of the equation.  Often integrators are given something very specific to be done, as well as a roadmap for doing so.  The architect takes part or creates that roadmap, and many more variables are considered than may be actually visible to the integrator.

Finally – there are various approaches that an architect learns to getting from A to B.  They learn to view a solution from a multitude of angles, and those which will enable them to see their way to the minimal path of risk.  In part, the approaches are part of the culture of the organization for which they must have an appreciation for, as well as a component of the overal IT & Business Strategies.

Hopefully that sheds a bit of light on the benefits of learning to become an IT Architect, rather than skipping these important steps.  For more information on training, see our site.

Happy Architecting.

And What’s the Difference?

It’s been a long time since I wrote part 1, but I’ll try to get the next few parts out asap.  If you recall, I was writing about the purpose and reasons for Enterprise Architecture.

Along with planning and strategy, execution is critical.  We must create and tailor our messages for our audiences in the most appropriate manners, and continually educate and grow support for the program.  If the business community cannot see value in this endeavor, then they are not ready.   That is yet another subject to be explored else where (ask me about readiness assessments).

You – the Chief Architect or Enterprise Architect, may have to put on a few public presentations – or private.  Each must be carefully crafted for the audience at hand.  If your organization is very green – well – they may need the “what is architecture” speech.  If they are more advanced, and you are purely looking for funding, you need to really familiarize yourself with the business strategy, cherry pick a few points, and then use a very carefully selected set of benefits and craft a presentation.

The presentation may have to be tailored for each audience you visit – the CEO/Funder, the CIO, other IT Groups, other business functional groups, consultants, and any other external support.  Before crafting the presentation, create a mind map or “story board” of your intended audiences and key messages that you wish to share.

Your sole purpose of such an exercise is getting buy-in!  It might not be actual funding, but you need to gain momentum so that you can get it once you ask.  They must understand before they can grant you their support.

Sponsorship vs. Support – There is a big difference!

Sponsorship is where a person or group pays for and assumes responsibility for the effort to be carried out.  This is usually the CIO, and potentially the CEO or IT Steering committees.  Support is someone or groups that support the effort or initiative.  They uphold, defend and promote EA as valid or the best approach by lending their assistance and public support.  Support is sought by all groups and domains that are affected and impacted by the creation, development and finally governance of the Enterprise Architecture.

Sponsorship and support require continuous education, promotion and communication.   If you want more information about the tools and resources you would need to uphold such an endeavor, get the entire report

Happy Architecting

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 (sorry – this link is gone – guess they were a little embarassed at all of the attention) 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.

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!

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!

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

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