Category Archives: Architecture

Writing Requirements … is HARD

Posted on by

An interesting bit from a summary from a Keynote by Martin Fowler:

Requirements gathering is also very tough on large projects. Martin provided an interesting comparison between writing requirements documentation and writing books. Writing a book requires a very large investment of time and energy. Even after peer reviews and feedback from professional editors, the author still is not always successful at communicating his/her intended message to the audience. His point was that if authors have a hard time doing this with books, imagine what it must be like to capture the requirements around a complicated business application given far fewer resources.

If a professional author is not always capable of communicating his/her intended message, what chance does the business have in getting their requirements across to IT with far less time, expertise and resources.

Set UML Free

Posted on by

Yesterday I received an invitation to support an effort to set UML free. You can read all about it on webuml.org. Currently the site is a wall of text (tip for the authors: less is more … and there is nothing wrong with a picture or two ;)) but if you have some spare time I encourage you to read through it.

The basic idea is to provide for online collaboration while modeling with UML. You can’t really do that today. The best you can achieve is to email some images of UML diagrams around or hope for the best with XMI. webUML aims to create an online collaboration environment using modern web technologies. They already have a powerful UML drawing canvas ready, including an integration with MediaWiki.

I see a future for this effort, if of course they can achieve minimal functionality (which I think they almost have if not already) and critical mass (that’s why they are promoting it right now).

There is however one thing that caught my attention: a promise for a plugin for Enterprise Architect from Sparx Systems so it can access a webUML central repository. If that plugin ever becomes reality and that central repository is HTTP accessible (sounds like a good REST challenge) they will have made me a happy architect. Integration with business tools and the business environment will be, in my humble opinion, key for mass adoption.

I would be really happy if there would be support for BPMN and creation of custom viewpoints and models (meta modeling).

But one should not ask too much and be happy with what we get. So please support the webUML effort, help if you can and spread the word.

While reading up on webUML I also came across this little gem: The Model Factory. A wiki on design patterns from the point of view of modelers. Implemented of course with webUML technology. Bookmark added.

Set UML Free!

From The Internet – 22/11 2009

Posted on by

Various resources on the Internet you might find useful. At least recommended reading for a spare moment.

ArchiMate and TOGAF. Four excellent papers comparing ArchiMate and TOGAF:

Some attempts at defining the concept of “business function:

Miscellaneous

Cloud IT as an Architectural Style

Posted on by

Martin Kuppinger from Kuppinger Cole, known from the excellent European Identity Conference, wrote a very interesting article on Cloud Computing: “It’s not about the cloud – it’s about Cloud IT“.

…

But the more you dive into the topic of cloud computing it becomes obvious that this cloudy thing of “cloud” (usually associated with the Internet and things which are provided there) isn’t the key thing. The key to success is that companies understand the value of Cloud IT.

What does this mean? Cloud IT stands for consequently using cloud principles in IT – and in every part of IT, not only for consuming some external services. That includes

  • well defined services (SLAs!!!)
  • a consistent service management across all services, regardless of where they are running (and, based on that, consistent approaches to cloud governance)
  • applications which are agnostic of where they are run or which hardware resources are available – there have to be parameters which might limit the ability to run applications everywhere and the application has to accept the currently available hardware resources but as well should understand that these resources can change dynamically

Defining everything in IT as services in a consistent manner is a fundamental change and the foundation for a flexible use of cloud services. Once you have made that move you can decide (based on parameters of a service) which service provider (internal or external) you will use. Thus, the first step is making your IT “cloud-ready”, e.g. moving towards a Cloud IT. Without that, using cloud services will always be sort of tactical and not strategic.

On the last day of the 2009 edition of the European Identity Conference I participated in a workshop on Cloud computing and Identity with Martin. In the workshop I told Martin that for me, an architect, the most interesting aspect of Cloud Computing is not the ability to house your application logic externally but a renewed and global attention for various architectural patterns.

The underlying current for most of these patterns is a high degree of abstraction and transparency combined with simplicity (not the bad kind, the good kind). In other words: keep it simple, abstract away everything that is not part of your application and don’t care about the environment you are running in (for instance network transparency). The advantages of following these principles are becoming more obvious due to Cloud Computing: scalability, continuity, flexibility, reusability …

Those patterns can equally be applied to classical internal IT. Yet, you rarely see this except at the application level. Cloud computing forces you into this thinking, traditional IT however gives you enough escape hatches. Not in the least because vendors keep on selling solutions that stifle innovation. As a simple example you can take the infamous network transparency. Demonstrated over and over again in the last 3 decades to be achievable (see for example the Inferno operating system) yet most commercial solutions still expose the network to you. So many good “inventions” but so little uptake from vendors.

In conclusion: I can only join Martin in his advice: get your IT cloud ready, move to a Cloud IT. Even if you will never ever actually move to the cloud. And more importantly, put pressure on your vendors to force them to innovate!

[edited: corrected some typos and grammar]

The state of TOGAF

Posted on by

It began with an article about the recent TOGAF conference written by Tom Graves. That article contained a quote I twittered:

We’re actually quite close to the point where a TOGAF certification is an indication that someone is not capable of doing enterprise architecture.

Twitter is a medium not really suitable for intelligent conversation. You only have 140 characters, there is no room for nuances or context. I did include a short url to the original article so people could get the whole picture. Nevertheless, the quote is out of context and that scared Tom.

In his follow up article Tom tries to explain where his statement came from. I hope that anyone understands that neither Tom nor I ever tried to say that people with a TOGAF certification are not capable of Enterprise Architecture. The TOGAF certification doesn’t differ from most other certifications out there. Having the certification does not guarantee knowledge and expertise. Not having the certification doesn’t mean you are inexperienced either.

The reason for me to twitter the quote was because I found it to be representative for what my generally feeling about TOGAF is. TOGAF needs a reality check, and soon.

In fact, Tom sums it up perfectly in his follow up post (and I urge you to read it instead of just depending on the cut and pastes I make):

  • he reference-architectures (Part VI of the TOGAF spec: ‘Technical Reference Model’ and ‘Integrated Information Infrastructure Reference Model’) are way out of date, and at the least need a complete overhaul, if not dumped altogether [that was from the Open Group’s lead Allen Brown, in one of the plenary sessions]
  • “almost no-one” uses the ADM in the form described in the TOGAF specification [in my last post I said I thought that was one of the guys from Deloitte, but my notes indicate it was Mike Lambert from Architecting the Enterprise, one of the lead TOGAF training groups]

These are two major shortcomings of TOGAF and Tom is not the only one mentioning them. Combine that with these two fundamental characteristics of Enterprise Architecture:

  • enterprise architecture is much broader than IT, and must now encompass the whole of the enterprise [that theme came up at least a dozen times, in plenary sessions and elsewhere]
  • enterprise architecture needs to be understood as a professional discipline, comparable to other professional disciplines such as medicine and building-architecture [again, many people, but particularly Len Fehskens, Open Group VP on Skills and Capabilities]

TOGAF has become enormously mal-aligned with Enterprise Architecture. It started in the wrong camp (IT) and even after a couple of versions (7.x, 8.x and now 9) it does not succeed in taking the right path. That is kind of ironic for a framework that is supposed to align business with IT.

Only in the last couple of months people start talking about some of the shortcomings of TOGAF. Everyone else is still covering up the shortcomings while making money from the “big TOGAF standard”. Each time you ask about some unclear element of TOGAF, the answer you’ll get will sound like “oh, but you don’t have to take that so literal, you have to adapt it”.

I sincerely hope we will get more people to speak up about TOGAF and get a significant better and mostly leaner version of the standard.

Encryption … no, we don’t need that

Posted on by

Kim Cameron recently went to a conference where he heard a cloud computing vendor utter these, and judging on the blogosphere almost legendary, words:

One of the vendors shook me to the core when he said, “If you have the right physical access controls and the right background checks on employees, then you don’t need encryption”.

Kim admitted he almost choked. I can understand him. We are in for some rough times if there are cloud computing vendors out there who think like that.

On the other hand I would like to take this opportunity to make sure you know that encryption in itself does not mean security. You can apply encryption all over the place, using keys that have a gazillion bits, and still have a unsecure, dumb solution.

Any vendor who replies “We use 256 bit AES encryption” when answering the question “How do you secure transmission of data?” is as dumb as the vendor who says “physical access controls and the right background checks on employees make encryption not necessary”.

Day two @ EIC 2009

Posted on by

I haven’t blogged about the European Identity Conference since it started. Although I have to say that I made up by using Twitter (@bderidder) during most of the keynotes and presentations. I was present at the very first EIC in 2007, skipped the 2008 edition and joined the 2009 edition again. That gives me a nice opportunity to see how this conference has evolved during it’s 3 first editions.

It has evolved … and mostly in a (very) positive way. Kuppinger Cole succeeded in creating a strong conference agenda with all important IAM and GRC topics covered. Even the catering is perfect! That was not really the case in 2007 during the first edition 😉

I do see a difference though. In 2007 there was this “grassroots” atmosphere. We had a lot of people working on emerging standards like Bandit, Higgins, OpenID, VRM … There was this constant buzz during the presentations, breaks and evening visits to Munich. Everyone felt as if they were part of this new thing called “Identity”.

The 2009 edition is different. It’s definitely a lot more mainstream. There is less of a buzz (if at all). I think that can mean two things. One, EIC is scheduling more “serious” presentations and, two, Identity has matured into something … well … mainstream. As always in these cases, it’s a little of both.

Heavily scheduling presentations about GRC (Governance, Risk and Compliance) is bound to create a more professional (dare I say boring) atmosphere. But, and that is a good thing, Identity is also a lot more mature. Most of the bleeding edge topics in 2007 are now being presented as commercial products and consultancy offerings. The best example would be all the offerings you can see around claims and XACML.  Topics like OpenID or SAML are not exotic anymore. They have become well accepted in the industry. One topic didn’t seem to make it though. “User centric identity” was lost somewhere in the last 2 years. It’s being recycled in the VRM (vendor relationship management) community but with less fanaticism.

Relating to my remark on GRC, hinting at it being a boring subject, I have to make a correction. It’s definitely not a boring subject. I would also say that Kuppinger Cole is absolutely right in scheduling it on the agenda. But you have to admit, it’s a more specialized subject with little to none “sexy” technical aspects.

The conference is not finished, it’s not even half way, yet I think I can make a couple of preliminary conclusions on what I will be taking home on Friday evening:

  1. Identity has matured, most of the exotic topics two years ago are now mainstream and being turned into products by Oracle, Sun, Microsoft, IBM … and numerous other larger and smaller players in the market. Clients also notice these offerings and buy them.
  2. It’s not clear if the current level of maturity of Identity is sufficient. There haven’t been any presentations on this and Kuppinger Cole is not making statements on this. Unless it’s about GRC of course, but what about other aspects? There are bound missing gaps in Identity right now and they are being forgotten in all the happiness surrounding claims, federation …
  3. There is a lot of talk about GRC, both in presentations and during breaks. Nevertheless, I personally still perceive it as something at a conceptual (hype?) level. That is at least the overall impression I got at this conference. Topics like these, high level business concepts, always carry a risk of remaining empty. It’s very easy to talk an entire day about GRC without knowing a thing about it, it’s a lot harder to do that with topics that have a direct technical link.
  4. Authorization is massively misunderstood and apparently has yet to reach the maturity level Identity currently has. Whenever the word “authorization” is dropped, people either go RBAC or think it’s about claims. It will probably take more then one year (and conference) to get this right.

I forgot some conclusions but since the conference is not over yet, I will get another chance to write about those.

For what it is worth, some advice for a 2010 conference:

  • Try to create some of that 2007 “grassroots” atmosphere, there are plenty of topics that can do this, both in Identity, Authorization and hopefully GRC as well.
  • Turn the GRC topics into something with real and tangiable content. It’s so easy to talk about GRC without actually saying anything.
  • GRC brings IAM to the world of “Business ICT Alignment”, that means to the world of Enterprise Architecture. So … where are the IAM and Enterprise Architecture topics?
  • Authorization definitely should come back and hopefully with the message that it is not about RBAC and not about claims. Those are merely tools and technologies that will have a much shorter lifespan then authorization itself. We have to dig deeper and unravel more of what authorization is really all about.
  • And last, an Identity Award for the longest blog post about day 2 of EIC 2009. Thank you.

Fake SOA

Posted on by

I came across this article from Anne Thomas Manes. She is probably best known for her article on the death of SOA. The article has an interesting quote (emphasis added by myself):

Most organizations that I’ve spoken with are using service-oriented middleware to do integration (SOI rather than SOA). Very few companies are actually rearchitecting their systems, i.e., simplifying their applications and data architectures in order to increase agility.

Most if not all “SOA efforts” I have came across in the last couple of years suffer from the above. The prime focus is on integration technologies: use a service bus as integration middleware. It is no surprise that most ESB products have a EAI background and just reinvented themselves as an ESB.

The second interesting item in the article (emphasis added by myself):

Instead they are using WS-* or something similar to implement open interfaces to their existing applications (i.e., JABOWS). Over time, JABOWS typically results in increased architectural complexity and systems that are more fragile and more expensive than ever before. Although initially the initiative appears to be successful, the long term effect is actually a failure.

In a previous job I regularly questioned the abundant use of SOAP and WS-* to create a Service Oriented Architecture. JABOWS (Just A Bunch of Web Services) is definetely not the same as SOA and indeed often results in a far worse architecture. SOA is not so much about the technology realizing the interfaces, it’s about the services you define as part of an overall architecture.