I’ve been answering a few questions in email lately, so I thought I’d add the questions in this blog:

Question: Do you see a big benefit from the Solution Architect Workshop (SAB)?  What’s the difference between it and the Information Architect Boot Camp Workshop (IAB)?

Answer: The IAB will teach you what the role of IT Architect is, how the various types of IT Architects are interrelated, how they fit into the project lifecycles, and how to be an architect practitioner.  You’ll learn the skills you’ll need to play any architect role and the basic architecture methods and process.

The SAB will teach you how to do solution architecture, review many options and put together solutions.  You will learn the skills as well as the steps and process to complete various Solution Architect activities and artifacts.  It is the best course for someone in a project architect role, provided the attendee already knows how or has basic IT architect knowledge and skills

Question: Should I take both of these courses together?

Answer: As we go through the IAB workshop, we are going to practice the various IT Architect skills as they are taught.  We’ll work on a project throughout the three day workshop, and each successive step will build on the previous, so that we will have gone through a typical Architecture activity from start to finish after we have spent three days together.

In the following two days in the SAB, we’ll learn more about putting solutions together and about the various scenarios the Architect faces when asked to create or update the architecture.  We’ll use the existing Architect’s skills if the attendee is just joining us, or the skills just acquired in the IAB if they are continuing.  It is not necessary to take both, but if you are a self-taught architect, it would be beneficial to take both together, to learn some of the best of breed approaches, and practices.

Question: What happened to the 1 day Architect Boot Camps – The Introduction and the Executive Architect Boot camp?

Answer: These training sessions have been held multiple times in the last few years and demand wasn’t high following the catalog release.  These classes are targetted to be offered as an online offering in October.  There will be some self-study, and some instructor/participant interaction offered.  More information to follow – stay tuned!

Question: Where are the classes being held?

Answer: Currently we are only scheduled for Winnipeg in October.  We have plans to offer some classes in Phoenix Arizona in 2009, and are currently looking into demand in other large Canadian and U.S. centers.  Classes are always available in group settings.  If you are interested in booking a class for 6 participants or more at your workplace, contact us for more information – choose the option of “other” for location and fill out the rest of the form.

Question: Do you offer a coaching and mentoring service?

Answer: Our online coaching service will be released today – more information later on.  We do also offer Enterprise Architecture coaching through EAdirections.  For more information on either of these services, please contact us, or watch for our information blast coming out shortly.  If you would like to get on our list for notification, please fill out the contact request form.

If you have more questions, or have other architecture problems or questions you’d like answered, please give us your comments.

Happy Architecting

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

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

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.

Happy Architecting