Studying TOGAF

Studying the TOGAF book was no easy task. The book contains 778 pages with a high information density. It is no easy read. We agreed to study TOGAF book chapter-by-chapter from cover to cover. In 10 evening sessions we would discuss any unclarities and questions we had on the material. In the process we learned a few lessons I want to share with you:

• It is not practical to read the book cover to cover. In the early chapters terminology is used that is explained much later in the book.
• The best way is to start reading part III (ADM Guidelines and Techniques) and part IV (Architecture Content Framework) and then read the actual ADM phases (part II).
• The book (or the online version of TOGAF for that matter) is not perfect, it contains some errors and creates some confusion of terminology. For instance: what exactly is a "building block" according to TOGAF? I took us hours of discussion to reach a consensus (which I verified with one of the authors of TOGAF when I visited the Open Group): a building block is everything. The same unclarity we had on the term "Enterprise Continuum" (read chapter 39 in the book). The same goes for the difference between artifacts and deliverables.
• Not all parts of TOGAF are of equal maturity. The ADM is quite extensive (although most details are in the technical architecture part), but for instance the chapters on security architecture, SOA and architecture maturity models are very thin

Apart from the points above (and some extra issues I forgot) TOGAF is still a very rich source of Enterprise Architecture information, containing many insights, checklists and models that can be used in practice.

It just needs a little bit more maturing.

Is your data safe in the cloud?

Almost all email infrastructures in business are similar. Email is not distinctive and are therefore often regarded as a commodity. But an email infrastructure is not as simple as it seems. End users want to read and edit their email in many ways and places. Processing email is often not only done from the workplace, but also from home, at customers or through a mobile phone. Email should therefore be accessible through various channels, and outside office hours. Companies must implement their email infrastructure accordingly. Another email phenomenon is spam. More than 90% of all email in the world is spam. Email administrators must implement adequate measures to prevent spam. Scanning email for viruses is also a system manager's task. All in all a lot of work for an email service that can be seen as a commodity.

An alternative is to us an email service from the cloud. The costs of using cloud services is generally much lower than maintaining an email infrastructure in-house. The reliability is high and management is taken care of. Especially for small businesses and start-ups using cloud based applications can be very attractive.

There are several providers of cloud based email services. Well known are Google's Gmail, Microsoft (Hotmail), but there are also many smaller providers active in this market. Google offers Gmail services for end users but also email services for businesses. There are 400,000 businesses using Gmail already.

It is important for companies to verify how security of data stored in the cloud (such as business-critical information in emails) is implemented. Before doing business with a cloud provider the contractual conditions should be checked. Some points to observe are:

• How does the cloud provider guarantee that data is securely stored and that no other persons or parties can access your data (do not forget to include the physical security of the data centers, is this audited by a third party?)
• How is it ensured that no data is lost, destroyed, etc. Is it possible that you - or an external party assigned by you - perform an audit at the cloud provider?
• What happens to your data when the cloud provider goes bankrupt, gets acquired or if the service is no longer offered?
• Where is your data physically stored? On U.S. servers? Is the data under U.S. law (such as the Patriot Act and SOX)?
• What is the exit strategy if you decide to move your data from one cloud provider to another? Is this allowed?
• In what format will you get your data back in such a case? Is the data in the cloud provider to actually destroyed? Can this be checked?

All valid points I think. But the big question is: Who really asks these questions to the cloud providers? I expect most companies that use cloud services (often for financial reasons) do not address all points above.

Or did I miss something?