What I would Change About ArchiMate

2 comments on this article Posted by Bavo De Ridder in Architecture on December 8th, 2011 .

ArchiMate 1.0 has been out for a while and ArchiMate 2.0 is months if not weeks from publication. Drafts for 2.0 have been circulating around a while now. The upcoming 2.0 version doesn’t change a lot to the core language. This new release is mostly marked by two extentions: one for modeling business motivatons and requirements and one for modeling the implementation and migration phases.

Most of what I was looking for in 2.0 didn’t made it. Here is a list of what I would have changed in 2.0 to the core language.

Define Business and Application Function as structure

It may come as a surprise but Business Function is not behaviour. Behaviour is the reaction a system has after being triggered by an event. Any behavioural element therefore represent instances that have a start time (when the event triggers), a result and an end time (when the result is produced). A business function is not such an element.

Most if not all meta models, including TOGAF, describe it as a structural element. In ArchiMate it would be a more logical version of a business actor. In other words, it’s an idealization of a business actor.

The exact same reasoning to move Application Function from behaviour to structure. An Application Function is a logical (idealized) version of an application component. TOGAF would call it a Logical Application Component.

Add Application Process as a core element

The business layer has a process element, why shouldn’t the application layer have it? An application service with the related application process would corresponds to a well known concept in IT: use cases. I would love to see them in ArchiMate!

Add dependency relationship

ArchiMate has tons of relationships, most of which should are hardly used, yet it misses one of the more important relationship: dependency. ArchiMate tried to avoid it by adding most of the specialized dependencies: Used By, Access, Realization …
But there are still places where I would like to use a simple dependencies without being forced to specify more detail.

Redesign the technology layer

ArchiMate is built around the distinction of internal versus external and behaviour versus structure. This is very visible in the Business and Application layer, especially with the above proposed changes. The technology layer is an exception. They tried to fit UML elements in this model and did a pretty good job. Yet, it feels wrong that the symmetry from the business and application layers is not showing in the technology layer.

I even wonder how wrong it is to have a behavioural item (System Software) inherit from a structural item (Node).

Something is not right in that layer and it needs to be fixed.


The Pragmatic Architects Creed … no thank you

0 comments on this article Posted by Bavo De Ridder in Architecture on November 11th, 2011 .

I got informed about a new deliverable from the folks from Pragmatic Enterprise Architecture: The Pragmatic Architects Creed. They collected a list of statements about architecture and ask you to sign it so you can show your support.

Since this felt like a good thing, I headed over to the list to sign it. Luckily I decided to read it first before I would sign it. In my opinion, most statements are too generic, some are plain wrong and only a small number qualify for my signature.

Here is the list of statements with my comments inline. See for yourself if you agree or not, leave a comment if you want to share some of your thoughts.

I put the interests of any organisation I work for above the personal or siloed interests of the individual that employed me.

Euhm … perhaps … never? As an architect it is my responsability to design a system that realizes as much of my clients wishes as possible while staying within the budget, time frame and the boundaries set by the environment. If that client is a business unit manager, I should only follow that manager’s wishes. If the manager asks me to try and go around some limitation set by the organization, than I will do so. It is up to the organization to set the boundaries.

If I wouldn’t do that, I would not be able to build a trust relationship between the client and me. My client would not experience me as someone who is helping him to achieve his goals but as someone sent from an outsider to make it difficult to reach his goal.

If the environment, the organization, wants to influence my design to make sure it serves the greater good, they have to do so in advance by setting rules. At a different moment, they can even hire me to do that. This is the role building regulations have in modern societies.

But honestly, as an architect I can’t serve two masters with potentially competing visions.

I can vehemently agree with someone about subject/point B when I have only recently vehemently disagreed with the same person about subject/point A.

I agree with this one. But is this limited to architects? To me this looks like a credo valid for any professional in any industry.

I love to be proved wrong.

Whoever claims he or she loves to be proved wrong, is lying. Nobody likes to be proven wrong. I do like to learn from other people and I am willing to adjust my ideas or statements whenever needed. Being proven wrong is never a good reason to stop learning or become unreasonable.

I relate new things that people do not know to . things that people already know.

I agree but again think this is a generic credo for any professional in any industry.

I spend more time understanding a problem domain than determining a solution.

Why? I don’t understand this one. If the problem domain is simple and the solution complex, I’ll spend more time thinking about the solution. I don’t see how you can objectively see this as a credo.

I stand up and give an unpalatable truth when no one else will, even though it may mean I lose my job.

Please do so, that frees up a spot for me ;)

But seriously, depending on the “unpalatable truth”, the context and the involved players, I’ll speak up or stay silent. I do take my responsability as an architect and I often do tell people things they don’t want to hear. At the same time I am not trying to improve everything around me nor do I stop people from learning from their mistakes.

I constantly ask myself and others; Why?

Nothing to add, I agree.

I see patterns and structure in everything from traffic congestion to Pop Music.

Given the previous credo … why? Why would it help me, my clients or the profession in general if I see patterns and structure in everything from traffic congestion to Pop Music? As an architect I must have a solid understanding of patterns and structure, those are at the core of the profession, but there is no need to see them in everything around me.

I can see disagreement between people when those people think they are in agreement.

This is a good one in fact. All to often I see people agree when they are in fact talking about two different things. As a person who has often more expertise in the subject, I see it as my duty to inform them they actually disagree.

I can abstract any thing or idea to a logical and conceptual level.

A solid understanding of idealization/realization is a must for every architect so I will agree with this one. I do feel a bit uncomfortable with the words “any thing or idea” however.

I never, by admission or omission, lie.

I would have agreed if it wasn’t for the word “never”. You can help people if you sometimes lie to them. Lying should be an exception however and must never harm. But as Robin Williams, playing the role of Theodore Roosevelt, said: “Sometimes it’s more noble to tell a small lie than to deliver a painful truth.” (http://btr.michaelkwan.com/2009/07/30/more-noble-to-tell-a-small-lie/)

I know the difference between a Model, a Metamodel, and Metametamodel.

Basic knowledge for any architect, I agree.

I know the difference between layers of abstraction; Contextual, Conceptual, Logical, Physical.

Is this a more generic version of the one about logical and conceptual level? I think so. I still agree.

I know the difference between Architecture, Design & Construction

One can start a civil war by discussing about the difference between “architecture” and “design”. So I challenge the author of this statement to explain the difference to me. Oh, one catch, the difference has to be described in a scientific and objective way. Definitions like “design contains more detail” or “architecture is about managing risk and cost” won’t cut it.


Writing Requirements … is HARD

0 comments on this article Posted by Bavo De Ridder in Architecture on November 11th, 2011 .

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.


Enterprise Architecture Wiki

0 comments on this article Posted by Bavo De Ridder in Architecture on November 4th, 2011 .

Something I stumbled across some time ago but forgot to share. There is a comprehensive Enterprise Architecture Wiki available. I haven’t browsed it extensively so I can’t comment on the depth, breadth or quality. But at least it looks promising.


Devil’s Architect

0 comments on this article Posted by Bavo De Ridder in Uncategorized on March 10th, 2011 .

Most of us are familiar with a famous quote from the movie “Devil’s Advocate”. If it was Devil’s Architect, it would sound like this (adaptation by me):

Let me give you a little inside information about Solution Architects. They like to watch. They are pranksters. Think about it. They give project managers architecture descriptions. They give them this extraordinary document with rules, guidelines and decisions, and then what do they do, I swear for their own amusement, their own private, architectural gag reel, they set the rules in opposition. It’s the goof of all time. Build but don’t couple. Couple, but keep separate. Separate, but watch dependencies. Ahaha. And while project managers are jumpin’ from one foot to the next, what are they doing? They are laughin’ their sick, fuckin’ ass off. They’re tight-ass. They’re sadist. They’re an absentee landlord. Follow them? Never.

Here is the original:

Let me give you a little inside information about God. God likes to watch. He’s a prankster. Think about it. He gives man instincts. He gives you this extraordinary gift, and then what does He do, I swear for His own amusement, His own private, cosmic gag reel, He sets the rules in opposition. It’s the goof of all time. Look but don’t touch. Touch, but don’t taste. Taste, don’t swallow. Ahaha. And while you’re jumpin’ from one foot to the next, what is He doing? He’s laughin’ His sick, fuckin’ ass off. He’s a tight-ass. He’s a sadist. He’s an absentee landlord. Worship that? Never.


Found: Identity Provider Business Case, or not?

0 comments on this article Posted by Bavo De Ridder in Access Control, Identity, Privacy, Social Networking on March 7th, 2011 .

I had the pleasure to have been part of the Identity community in the “early days”. Right before OpenID came into existence and most people thought of Microsoft Passport as innovative. One very hot topic was the idea of an “Identity Provider”. An Identity Provider is a party on the Internet who would be happy to serve any claims about me to a any relying party, obviously with the user’s consent and control. Anyone remember the expression “user centric identity”?

There were some unsolved issues:

  • How would an Identity Provider make money to pay for the operational costs?
  • How would relying parties know which Identity Provider to trust?

Especially the second issue was hard. Some relying parties just want to be able to recognize recurring visitors and are happy with a couple of standard attributes. For them, identity has low value. Well known examples are the myriad of forum sites.

Other relying parties however want more, they want identities with verified attributes, an identity they can trust. For them, identities have value and untrusted identities come with a business risk. An extreme example would be a financial institution who would, for these reasons, typically never outsources the Identity Provider role.

A couple of days I came across an interesting article about Facebook offering their commenting system to other sites, including authentication through Facebook. What caught my eye was an argument showing that Facebook serves as an almost perfect Identity Provider in some sense:

This offers publishers a number of benefits. They get more links to their site from inside the net’s most popular website. A lot of people are “registered” to comment on their sites. And, they have a system designed to discourage vitriol because it’s easy for the site owner to ban a user and tough for a user to create a new identity.

Especially that last part is interesting: relying parties can put some trust in the provided identities simply because … people invest time and effort in their Facebook identity and generally would not throw this away just to post rubbish on some forum. In other words, relying parties will like Facebook identities. They trust one Identity Provider, Facebook, and they get hundreds of millions of fairly trustful Identities.

But what is in it for Facebook? A lot!

For Facebook, the benefit is also clear. Users now have even more incentive to be constantly logged into Facebook (those who are already logged into Facebook don’t have to do anything to comment on a website using its system). Additionally, even more of Facebook’s users’ net activities flow through its site, since by default comments — and replies to them — post to a Facebook user’s wall. That deepens users’ ties to Facebook, adds more content to Facebook, and gives people more reason to check their Facebook newsfeed for the increased information flow.

By allowing relying parties to use Facebook identities to realize a comment system on their site, Facebook actually generates value for themselves. A win-win it seems.

Facebook, with their Facebook Connect, wants to be the primary Identity Provider on the Internet:

It also builds on what’s becoming Facebook’s most important function: being the identity provider and validator for the wider net. The system opens the door for what’s likely inevitable: having news sites rely on Facebook to identify its users and eventually to serve ads to its readers based on their individual Facebook pages.

Both issues are gone: the Identity Provider (Facebook in this case) can have a very viable business model and the relying party has an Identity Provider they can trust, one that brings hundreds of millions of identities.

So, all well now in the world of Identity? I don’t think so. The relationship between Facebook and relying parties is not a balanced one. Relying parties are clearly at the mercy of Facebook:

… just as Facebook jealously holds onto the e-mail addresses of the people you are connected to on Facebook so you can’t re-establish your network on some other site.

Promising as it may seem, this type of unbalanced relationship should not satisfy us. So, for those still active in the field of Internet Identity, what do you think about this?


Automating Business Services in ArchiMate

8 comments on this article Posted by Bavo De Ridder in Uncategorized on September 27th, 2010 .

02/10/2010: after posting this, there were some insightful comments made. I encourage you to read them as well.

I am generally very enthousiastic about ArchiMate. What is not to like? It produces elegant models that are easily understood by a broad family of stakeholders and the viewpoint categorization is refreshing and very useful, especially compared to for instance TOGAF 9. It’s not all sunshine however, there are for instance a couple of points in ArchiMate where I tend to differ in opinion with some fellow architects.

One of those points are the assignment relations between the application layer and the business layer as shown, using bold red, in the following subset of the ArchiMate 1.0 metamodel.

Before I go any further I have to state this disclaimer: I will explain my point of view given my current understanding of and experience with ArchiMate. If you have any remarks, negative of positive, on the reasoning presented in this post, I would appreciate if you would post a comment or contact me directly!

Metamodel (click to enlarge)

According to the specification (see Chapter 7 “Cross-Layer Dependencies”) these relationships have the following meaning:

Assignment relationships, between application component and the different types of business behavior elements, and between application interface and business service, to indicate that, for example, business processes or business services are completely automated.

In short, in case of complete automation, you assign active structure from the application layer to the business behaviour instead of the, usual, active structure of the business layer (actor and role). With this active structure from the application layer, an application component, comes the external structure, an application interface. The application interface will be the interface through which clients use the business service.

Let’s develop a small and simple example where we use these relations, explore their meaning and identify potential pitfalls.

A company offers a customer support service to their customers, this service, “Customer Support Service”, is realized by a business process “Customer Support Process”. This process is executed by the customer support department who offers a phone interface for customers. The process itself is fairly simple, first the support request is analysed, then a knowledge base is searched to find possible answers, the possible answers are combined into a support answer for the customer.

As you can read in the process description, the actors in the customer support department use a Knowledge Base application. They access it through a web interface. This application offers a service where you can browse and search common problems and their resolution. The customer is not directly exposed to this Knowledge Base application. The model belows shows these elements and their relationships.

Example #1 (click to enlarge)

We haven’t yet used the assignment relations between the active structure of the application layer and the behaviour of the business layer.One way to introduce them is to simply state that instead of offering this service using the customer support department, it is completely automated with direct access to the Knowledge Base application. The Knowledge Base application is capable of performing a simplified version of the Customer Support Process and the customer directly accesses the web interface. The business process has to be simplified before it can be completely automated. Our Knowledge Base application is not, as most applications aren’t, capable of intelligent analysis of the support request or possible resolutions.

Example #2 (click to enlarge)

The above simplified situation, with only a completely automated realization of the business service, is not very common. In most cases the customer can use both interfaces. The Phone interface is offered for customers who are unable or unwilling to use the web interface or whose questions are just too complicated and require a customer support representative. The web interface is offered in case the customer has access to the Internet and is able and willing to use the direct web interface. At first sight we can simply model this as seen below.

Example #3 (click to enlarge)

But is this correct? We have an application component whose internal behaviour is represented by a business process, it completely automates the business process, But this process behaviour itself uses an application service that is realized by … this very same application component! That sounds pretty much like an endless loop. I don’t think it is impossible as such, depending on the level abstraction level of the process definition or the level of composition of the application component, you could defend the above model. But honestly, I feel it would barely represent reality.

It is clear that we want to avoid having a business process that uses an application service that is implemented by an application that itself completely automates that business process. Yet, the situation with two interfaces to a knowledge base, one offering access through a customer support representative and one offering direct access to the application, is very common. Both interfaces support the same buFsiness service, they both fulfill the same customer need. We can’t use a single definition of internal behaviour though, so let’s update our example and define an extra business process. This new process is a simplified version of the original process that only allows simple questions and is therefore easily automatable. This new situation is shown in the diagram below.

Example #4 (click to enlarge)

The above example has been kept as simple as possible. In practice it would be unlikely that the original web interface of the knowledge base application would be considered usuable by customers. In most situations you will find a new application that offers a more suitable interface for end users, this application will use the original knowledge base application through an application-to-application interface (this interface is not shown on the model).

Example #5 (click to enlarge)

These simple examples show my current understanding of these particular relations in ArchiMate. If my understanding would be incomplete or even flawed, I hope to find constructive comments to enlighten me.


Enterprise Architecture Conference Europe 2010

0 comments on this article Posted by Bavo De Ridder in Architecture on June 10th, 2010 .

For all you (enterprise) architects out there, I’ll be at the 11th Enterprise Architecture Conference Europe 2010 in London next week.

I will be Twittering at @bderidder and I hope to write on this blog a couple of times. Not sure what the Twitter tag will be, but I’ll find out next week.


My pin code is … ****

0 comments on this article Posted by Bavo De Ridder in Security on February 24th, 2010 .

Yes, you read that right, I gave you my pin code, it’s … ****. Of course, unless you lack a brain, you know that **** is not even a valid pin code. It’s what you see on screen when you enter your code at any ATM. No need to protect that … or is there?

One bank in Belgium goes to great lengths to protect you from devious people trying to read that “****” while you enter your code. They have a special film on the display that makes it impossible to read the display unless you are standing perfectly in front of it. So, nobody can read that “****”, only you can. They even have a sticker on the machine telling you how they do their best to protect you.

They do not protect you in any way from someone looking at what you type on the key pad though. In fact, from the looks of it, they do their very best to make it as easy as possible for strangers to see what you are typing on the key pad.

I know many of their ATM locations are surrounded by excellent spots from which you can undisturbed see any pin code being entered on they key pad. Even when the ATM is indoors, it is conveniently located near a large bright window. A large bright window lacking any protecting measures for that matter. Someone living in the house opposite the street can easily farm many pin codes a day.

It’s good to see how smart people are doing their very best to protect me from fraud and theft. Thank you.


Some still don’t get it!

0 comments on this article Posted by Bavo De Ridder in Access Control, Security on February 2nd, 2010 .

This post is about security, so if you are not into that, feel free to skip it.

Today I get a friendly email from the national railroad company of Belgium (NMBS) in which they announced a brand new site to order international train tickets. It also mentioned that instead of using my made up user name I could now use the email address I used while registering to log in.

That sounds great, another site that uses an email address to log in instead of something like “johnsmith342″.

Then they kind of messed up. For my convenience and to make sure I would be able to use their shiny new site to buy lots of international train tickets they included my password. Yes, you read that right, they mailed me my password. Without me asking for it.

They have no clue about processes and procedures for dealing with passwords. They are not helping the world in teaching people how to deal with authentication secrets, social engineer and phishing.

I can only hope the password is not stored clear text. Due to password policies it is often necessary to access the password in clear text, only storing a hash is not working any more. Common databases like Microsoft Active Directory, Novell eDirectory and probably many others use two way encryption to store passwords. They have many secure access layers between a public api and the encryption keys to access to the clear text version of the password.

Honestly, emailing me my own password without my consent doesn’t generate a lot of trust in how they deal with sensitive information. That includes my trust in how they store my password in their systems.


Previous entries

Bad Behavior has blocked 422 access attempts in the last 7 days.