Fake SOA

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.

Microsoft on ‘Building Security In Maturity Model’

Last week I went to a presentation on the Building Security In Maturity Model by Gary McGraw. They interviewed about ten organisations who did have a software security team and asked them what they actually do today to make software more secure. They specifically went for a data-driven apporach, no “what could we do” but a 100% focus on “what do they do”. Piling all that information together, some magic processing (read: spreadsheet magic) and you have the Building Security In Maturity Model.

Microsoft was one of the organizatons participating in this effort. Steve Lipner himself wrote about how he experienced this effort and what he thinks from the outcome. One part of his article I would like to emphasise:

I’ve historically not been a fan of “maturity models” because many of them are so abstract and paper-oriented that you can rate “high” on the maturity model and still fail at whatever attribute of your products and processes (quality, timeliness, security) the model purports to measure.  In contrast, I like the BSIMM because

·         It’s specific.  The measures in the BSIMM are things that an development organization actually does to produce secure software.

·         It’s real-world.  Gary, Sammy, and Brian made a rule that no activity would be included in the BSIMM unless at least one of the organizations they interviewed actually performed that activity.

I have about the same idea on maturity models as Steve has. But then, I am mostly sceptical about any model and framework that abstracts away reality so vigorously that I wonder how any organization can successfully use them to achieve improvement.

TOGAF, Zachman … obsolete?

I stumbled accross this tweet from Danny Lagrouw:

Dion Hinchcliffe #qcon: “Architecture frameworks like Zachman, TOGAF, DODAF etc. aren’t keeping up with today’s web technologies.”

I found it interesting since it aligns with my own mixed feelings about these frameworks. On one hand they seem to do a good job on formalizing (enterprise) architecture but on the other hand I wonder if any organization can successfully realize their architecture, using those methods, in today’s rapid and agile environments.

Design Secure Software

Repeating an article by Bruce Schneier is kind of useless. I assume everyone even remotely related to information security has his blog as the first thing to read every morning. Nevertheless I’ll give it a go for those not yet aware of this excellent source of insight.

From his article titled IT Security: Blaming the Victim, I was happy to see these two quotes:

The solution is to better design security systems that assume uneducated users: to prevent them from changing security settings that would leave them exposed to undue risk, or—even better—to take security out of their hands entirely.

and (emphasis added by me)

The legal system needs to fix the business problems, but system designers need to work on the technical problems. They must accept that security systems that require the user to do the right thing are doomed to fail. And then they must design resilient security nevertheless.

There is absolutely not enough effort going into designing secure software and solutions. As I said before, too much energy is spend on dissecting vulnerabilities without even hinting at improvement. At the other end of the spectrum, organisations are spending large amounts of money on information security plans, risk analysis and governance but neglect to address securing the software that manipulates the assets they want to protect in the first place.

Embarassing Facebook Moments

Paul Madsen confesses he was able to, just in time, avert an embarassing Facebook moment:

On what started as an innocuous thread on the relative merits of curling and football, comments were made by a non-work friend that, while completely appropriate to the relationship between myself and the commenter (we having a long history of questioning each other’s masculinity and mental health), were not appropriate for a work context (or 98% of any other contexts it must be said).

Paul also points to what he thinks is the root cause:

The fact that my Facebook friends list is an aggregation of both work and non-work hit home yesterday.

Facebook allows me to create lists but not, AFAICT, use those lists to compartmentalize through differentiated permissions, e.g. allow members of one list to participate in a thread and not another.

Since the first day I have been using Facebook I felt very uncomfortable with the way various friends list are managed. On Facebook, you always risk having embarassing “red face” moments when you have different types of friends list (work and friends for instance).

Facebook does have various settings related to privacy, who is allowed to see what, etcetera. But honestly, even I sometimes have it difficult to configure those in a way that I am confident no information is spilled from one group to another. Currently I even practically closed down my Facebook profile for everyone who is not a close friend. If you are not a close friend, you will only see some very basic information about me and that’s it (if you do see more and don’t consider yourself a closefriend, drop me line ;). But even with all careful configuration work, I know I will one day face a “Paul Madsen Moment” on Facebook.

Clearly, offering a bunch of configuration settings like Facebook does not solve the issue. First, it becomes (too) complicated very fast and second, even when configured properly, it still has open holes. Who has a good solution that works in complex environments like Facebook?