TOGAF training

Architecture Development Method

Last week I went to Utrecht to get educated on TOGAF, a framework for enterprise architecture.

The first day was a bit messy to get there. Arriving in Utrecht I took a cab to the wrong address but eventually I got on my destination, albeit a bit later than expected.

In this initial day we looked at the overall scope of TOGAF and its Architecture Development Method (ADM). At the end of the day, I wondered if TOGAF could be applied in an agile/lean manner, surely something I will look in to.

During the other days, I constantly tried to imagine how TOGAF could be used for the customer where I'm working for at the moment. I do believe that I can go back to work next Monday with a better understanding on how to approach the Enterprise Architecture journey. The good thing about the methodology is that it not only provides a guidance during the EA exercise, but also guidance on how to set it up. This is especially interesting for the situation that I'm in at the moment.

I also found it very interesting to learn how TOGAF deals with the management of artefacts that are produced or brought into the Enterprise Architecture. I believe that the repository that I've started with will look a bit more different from now on. However, the simple SharePoint setup is still sufficient for this job if you ask me.

In this course I really learned that demystifying complexity by using various viewpoints for the different stakeholders is a really important aspect. If this helps to get the stakeholders in line, then it is a job well done. Secondly there is time and space foreseen for finding and dealing with cross project synergies, a topic that I believe is much needed in my current company. The part about governance was a bit heavy and tuned to the bigger enterprises, perfectly fine I just need to figure out how it can be downscaled to the appropriate size for us.

I had one disappointment on the chapter about requirements management. In my simple mind I was misled by the size of the circle on the ADM and thus I had pretty high expectations about it. It came out that TOGAF specifies the importance of it, but not really a way to accrue or manage these requirements. I reckon that this is subject for a different course :)

I would like to thanks Rienk de Kok of the-unit (www.the-unit.nl) for his dedication during the course, he's a good instructor that I would advise without a blink. Secondly I would also like to thank the other 11 attendees as they made the course even more interesting.

Next step is to turn the theory into practice, but that's food for a next post.

The journey begins

The first week

Previously I wrote about the ramp up towards the Enterprise Architecture in my company. I would like to continue on this topic by giving a short story on the first week.

In the past week I continued to tour the company explaining about enterprise architecture to make sure no one got excluded from that story. The reactions seemed positive and people look forward to it. So far the message was spread in the IT organisations as they were closest to me, always easier to speak to kindred spirits :) However, I know that a similar message has to be told to the business, but therefore I'll need a different text with the same meaning.

Starting the enterprise architecture is not something that is easily done. I consider that a lot of preparation is needed, but we still want to provide short term value. As said in the previous topic, a lot is about communication for us at the moment, connecting people. Openly discuss topics even across project boundaries and be transparently in that communication. Additionally we also need a better document management solution than a network share that just doesn’t cut it for this purpose.

Luckily the company just rolled out Office2010 and SharePoint, so I took advantage of the situation and immediately started populating all architectural artefacts that I knew off into SharePoint. The intent is to attribute all documents in their based on the TOGAF meta model so that we can use SharePoint as kind of an architecture repository and a communication channel at once.

Besides setting up this environment, I did spent some time on the project level where I got invited by my colleague architects. They look forward to address the cross project concerns as they use to fall out of the equation at the end of the day. I do hope to find a way to gather and consolidate all these additional requirements and bring these forward to the Architecture forum (IT management) where they can be evaluated and perhaps even planned in the IT roadmap. 

Next thing on the menu is a TOGAF course in the Netherlands that will hopefully provide me with a good deal of theoretical knowledge to take our Enterprise Architecture a step further.

Stay tuned :)

The face of a new target enterprise architecture

One of the tasks on my menu is to facilitate and drive the exercise of our target Enterprise Architecture, in short, our big picture, the master plan. The question is, do we derive it from our current situation but an improved version of it, sort of, will we start over and fix all the pain points of today. But what guarantee do we have that we'll do it the right this time? Will we end up a few years down the road in the same situation as we are today, getting the feeling that our technology is hampering the companies agility and innovation. This brings up the question if we actually need to invest big time into our future, maybe we should just go into the direction of throw away architectures, much like we replace our dining room every now and then with low budget Ikea furniture. Would this make us much more agile, would this result into a continuous moving and transforming company?

When I think about it, I believe some things are stable over the the years, consider a purchase order or an invoice, they're still around since the early days, there still similar today than my first school example a few decades ago. So, where is the variability then, is it in the products, they do change continuously and more and more rapid everyday for most companies. I believe the difficulty lies in the zone where the variable meets the invariable. Today most ERP's and custom (legacy) front/back office platforms have a polished end to end process. Sales tools, CRM systems etc, all mix the complete business processes together. The data that is involved with for example a traditional print advertisement is completely different that the data involved with an online ad. It are these differences that really change the internals of ERP's and custom build platforms. The business people they do not always understand, for them it is just another product, true some characteristics that are different, but they usually don't understand the fuzz from IT departments when they conceive new products.

So, what if we would architecture our IT landscape in such a way that the stable invariant processes are based on solid proven enterprise packages. The more the nature of the business process and its related data/information gets variant we want to structure this as minimum as possible, don't make it too rigid because it can change over night. With this attitude we are not bothered if we throw away something. This brings me to the next question then, what would we use to support the more variable business processes? Well, I believe that today we see more an more consumerization going on, where consumer products our serious alternatives to use as complementary means in the enterprise. For example, just replace a rigid ever changing discount approval workflow setup (that is usually changed when it ready) by giving sales force a communication tool like skype and they can just simple ask their manager if they are allowed to give that extra discount for the customer they're facing. Does it really need to be so well structured, controlled, formal, rigid, etc or is it exactly this space that warrants business agility if we do provide freedom.

Today employees are far more advanced PC and internet users than 10 years ago. I always said in modernization projects that the tools everyone uses at home - from operator to the CEO - influence the wishes of the next platform they have in mind past the green - and gray screen application era's. Today I believe more and more that these very same tools will not only be an inspiration for the enterprise but will be the very products used in the enterprise itself.

There are still a lot of other questions, for example how do managers monitor, process and correct their operations without proper information or without their important KPI's? It is my believe that simple and seamless BI will play an important role in this, so BI will move from an support/optimization position to a crucial core component of the overall architecture.

All of this could lead to an enterprise that operates on solid proven standardized platforms complimented with commodity/productivity tools and consumer products. Make sure you serve the business user properly on the stable processes and empower them in the variable bits and give them the means to be creative and innovative.

Enterprise Architecture start-up

The beginning of the Enterprise Architecture

A few weeks ago the project I was working for was put on hold, 7 months of my time to waste? No, definitely not, I learned a great deal on the overall organisation and had the opportunity to look into most of the companies business processes.

After the project, I started working on a proposal for Enterprise Architecture, something the company is in need of and they were looking for an Enterprise Architect anyway. I figured, I can do a lot of stuff that this new (Enterprise Architect) lad can pickup later on, who knows, I might be able to join him and work together in the space of EA.

Weeks went by and the my story became more and more clear, we only had to wait for the Enterprise Architect to arrive. In the meanwhileI I started to get in touch with people and communicate my message that EA will be there and that it will offer a great deal of guidance in our ever transforming company. I invited myself to a lot of architectural flavoured meetings and gave my recommendations for topics like SOA etc. Eventually it came to the point where I brought my message to the director level and even to the CIO who were all very interested as they saw some things that could help them with their struggling IT strategy and roadmap. It became apparent  that I had to step forward and so I did; and so the companies Enterprise Architecture journey began.

Ok, we have the attention, what now?

Right, here we are, lacking years of experience in various EA frameworks like TOGAF, Zachman, or any other (btw, used to be a software architect most of the time), however, I believe I have a number of good ideas, none of them are structured into a big master plan though. When I was in the CIO's office the other day, he asked me some questions like; we need to get our IT strategy right by the summer (in a few months), can you have the new to-be architecture ready by then. Walking out of the office I honestly had no idea if I could pull it off,  I know I'm capable, just don't know if the CIO and I are, time-wise on the same level.

So, to the drawing board. I kind of figured that we need an approach first:

1. Communication: align on tooling, align on business language (glossaries), align diagram notations, centralize documentation and communicate as much as possible about the existence of the EA. 
2. Guidance: Assist the architects in topics like SOA, train, educate them on the little agreements and visions that we have so far. FInd and advocate industry standards and keep an eye on industry trends.
3. Advice: Be there for the strategical level to form an advisory body and to make recommendation. Provide architectural input as soon as possible when new projects are being conceived.
4. Governance: I know we have to get to a pragmatic level of control, with room for creativity & innovation, how it will look like is unclear for me at the moment.

So if this is the path that we'll follow, what are the actual deliverables that are going to be produced and which of these bring the most value in the short term both to strategic, tactical and operational level? I first thought on getting a good picture of the As-Is situation, but after reading Jon's  post about "To Be or Not To Be" I changed my mind, so that's one I'll park for now. In the company, one of the "broken" things sterns from data ownership, more specifically I see teams fighting (bit strongly expressed, but you get the idea) for data and functionality for which I found a good paper from MIT "Information Politics", still have to read it though.

Right, this is the EA start-up in a nutshell, lots of reading to do though, however I feel that I need to catch up quickly to deliver some value, so need to be smart about it, but that's some food for next post :)

On Twitter

For those who are interested, you can follow me on twitter which I'll use for my professional career. Most of my ups and downs in the journey of Enterprise Architect will be posted over there. As allways it might be usefull for some1 following similar directions. Enjoy.

twitter: @eriklenaerts