Open Source Secure Projects A client I work with mentioned that for high security related projects, that developing them in an open source way will actually decrease the security provided by the project. The idea being that if anyone can see the architecture and code while it is being developed they can prepare to compromise the security. This made sense at the time and I nodded, but after chewing on it for a few weeks I think this is not the case at all.

There is certainly the argument that implementations are not open source. Of course that makes sense as no one will open up the server configs, passwords, private keys, etc. But the actual software that is used within an implementation gets more secure if developed as open source software.

So here's the short list off the top of my head of security related open source projects that are pretty widely used:

• Advanced Encryption Standard (AES/Rijndael) - approved by NIST in 2001. First open cipher used by NSA to secure top secret information.


• OpenSSL - Since 1998


• OpenSSH - Most widely used SSH implementation with over 80% usage [source]


• SELinux - NSA developed linux security


• Gnu Privacy Guard (GPG) - implementation of OpenPGP for signing/encrypting using PKI


• Trusted Solaris - developed by Sun under OpenSolaris


• Plus lots more that I can't think of right now...
  

Of course others have written on this subject and pretty much conclude that not only does OSS improve a project's security, not being OSS is quite a large vulnerability.

Labels: OSS

  ¶ 2:34 PM 0 comments

  No Cost SOA One of my clients came to me a few weeks ago with an interesting challenge: They want enterprise SOA, but have no money. This client is an extremely federated organization with multiple IT groups all receiving their own funding.

There's definitely a need for enterprise SOA (governance, infrastructure, practices) but no authority to back anything official.

So in light of these restrictions, we're thinking of a two-pronged approach to assisting SOA efforts:

1. Try to convince IT authorities of need for formal SOA
   
2. Collaboratively create SOA practice and standard recommendations that development groups can follow.
   

Step 1 involves building business cases, roadmap documents and other goodies that help convince those in power that it is worth spending money on SOA.

Step 2 involves documentation developed by the various IT groups building SOA around the organization. These documents include a service development lifecycle recommendation, service definition process recommendation, governance recommendtion and interoperability best practices recommendation. These documents are to be developed in a collaborative fashion (think wiki) and will be the self-selecting SOA community's guide for how to develop and use services.

Step 2 certainly has challenges (who will make people follow the recommendations- answer no one), but should move the organization closer to full SOA while cutting down on the chaos. I like step 2 because it gives an answer to the "no funds paralysis" that makes some architects think that SOA is hopeless.

I'll post updates as to how these approaches end up working.

Labels: SOA Governance EA

  ¶ 7:36 PM 2 comments

  Free/Libre Open Source Societies Chris Anderson published Free! Why $0.00 Is the Future of Business last month and it got me thinking about some of the business/technical associations I associate with.

Over the years, I've been a member of a few groups: IEEE, IASA, AJUG, NYJSIG, etc etc. I'm also familiar with some of the major professional organizations: PMI, OMG, IETF, W3C, JCP. Some of these were free (IETF, AJUG, NYJSIG) while others required membership dues (IEEE, OMG, PMI). Some started out free and transitioned to membership dues (IASA).

In some of these organizations, the membership fees very clearly show what they go towards. For example, in the IEEE, you get a magazine, group rates on health insurance, etc. In others, I'm not sure what the dues go for: IASA.

Specifically, for architecture and programming groups, I think that the price for admission should be free and have tiers for additional membership if you want magazines, keychains, etc. This will serve to increase membership while keeping leadership in a purely voluntary capacity.

So this ends up being more closely aligned with open source "societies" like the apache foundation where anyone can be part of the community, join listservs, register for conferences, etc.

Labels: business

  ¶ 1:24 PM 0 comments

  SOA Registries- What I need I was cleaning out my briefcase and found some notes I had written down about what characteristics I need in an SOA registry (or repository if you're one of those people).

I've seen almost all of these features spread out across a couple of different products, but I think eventually you will need these in order to have a successful SOA implementation. Each of these items deserves a whole post, so I'll keep it brief in this post.

A last note before I start enumerating is that I think SOA Registries are more useful at the private/internal/enterprise rather than the outdated public UDDI model of 5 years ago. Registries needed to enable an enterprise's modular development, but aren't required for locating public services as it's pretty much impossible to get all the different providers together in one registry.

• Service Level Agreements- the SLAs available for the service should be listed out so an architect or program manager can search based on what is compatible with their system needs.


• Security - what kind of authentication is needed for the consumer to implement. Here's where you get all the various metadata that tells potential service consumers the kludgy way that userids. Until an enterprise gets their single sign-on, SAML compliant wonderland authentication framework in place, you can look to the registry to see if a service needs basic auth (and where to get a userid), digital certificates (and where to get a cert), custom headers, etc etc.


• Data classification - what kind of data is passed in the service. I'm currently dealing with this in the public health sector as there are special regulations that kick in when you deal with Personally Identifiable Information (PII).


• Endpoint - of course this is in the WSDL, but for non-WSDL services, you have to have the endpoint.


• Service Interface/Schema - again, another item in WSDL, but this needs to be available for POX, etc.


• Examples & Documentation - essential to have links to example client calls and user documentation on how to use the service. This sounds like a no brainer, but every time I've had a "WSDL only registry" there is always reams of extra work that goes into demonstrating how to call the service. An even better way of documenting the service is to provide test programs/classes that a potential user can download and play around with. Don't assume that all your users have fully licensed SOA tools.


• Approval Level/Rating - this should show what approvals and governance checks the service has gone through. Is this a demo service? Or does it meet all the necessary service characteristics that the service governance center came up with. Think of this as a stamp of approval. You don't have to limit this to just a formal approval, think of a digg/reddit type rating where users in your systems can add their thumbs up to a service. Word is going to get out if developers across your company like the service anyway, make it easier for them.


• Providing organization- who built this service. This is especially important in a federated repository where it is not necessarily clear who is responsible for maintaining a service.


• Version/last updated - not only showing the current version but other related versions.


• Timeliness- how long is this version guaranteed to be supported.


• Keywords/tags - service provisioners should add keywords to allow for easier searching and finding of related services.


• Usage statistics- how many executions per time period, average time of execution. Stuff like this. Implement service performance measurement and publish the results as part of the registry.


• RSS for updates and announcements - allow consumers to subscribe to a service's feed to see when a new version is coming out, known issues, etc etc.


• Cost/chargeback model- if your enterprise charges for services (which has its pluses and minuses as Nick Malik pointed out) then go ahead and show it as part of the registry. Buy 1,000 transactions, get 1 free.

So that's a couple of useful things that I'd like to see in my service registry. It goes beyond what some of the big vendors are selling by adding in some user centric features. Don't think that this is all based around bottom-up as there is still governance and all the other stuff that goes into the review a service is put through so that it can make it into the registry.

Labels: SOA

  ¶ 3:52 PM 0 comments

  Technology Architecture without sound Business and Service Architecture? One of my clients asked me a pretty common question this week:

"Is it possible to develop a Technology Standards Profile (Technical Reference Model since we're in the FEA space) without working on the Service Component Profile?"

I will also add the question of whether you can do this without the Business Architecture.

His goal is a valid one: his organization has many disparate divisions and teams building IT systems and he wants a list of technologies that should be used to prevent using everything under the sun. His constraint is that they do not have the performance, business and service component architecture built out and he wants this concrete set of technical standards soon, rather than once the entire enterprise architecture is complete.

Of course, this is possible to survey the organization and create a list of all the technologies used. But in order to develop a set of technology standards for developing new systems, you really have to know which technologies stay, which ones go and (more importantly) what new technologies need to be added. The value of this analysis increases as you know what business drivers are determining what services will need to be developed. This will drive your technology.

In order to combat the pushback of "Don't tell me I can't use Java/Microsoft/Mainframes/whatever", you need a solid business case supporting the technology standards profile. Inevitably, if you don't have the solid grounding and line of sight through the entire architecture to justify technology standards you will start out with grumblings and skunk works trying to prove why their technology is best and should supplant the status quo (which sometimes is successful, but not always).

So the answer to my client's question is a difficult one for him: You're going to need an architecture that addresses the business, performance model and service/applications in order to reach your final goal of a technology standards profile. This means he'll need more resources and a tougher sell to his management, but it seems like at least 20% of enterprise architecture is justifying the benefits.

Labels: EA

  ¶ 7:38 PM 0 comments

  IBM SOA Certification IBM announced two weeks ago that they would launch a free 12 week SOA mentor program to their IT certification program.

Just email fedsoa@us.ibm.com to register for the program. There's a real world meeting on Sep 12, but everything else is through email and webex.

You still need to pay for the exams, but free classes are cool.

Labels: SOA

  ¶ 9:13 PM 0 comments

  Enterprise Architecture is IT speak I was recently at the PHIN 2007 conference facilitating a stakeholder group on collaboration and witnessed the following conversation with state and local public health partners:

Person A: We would benefit if we had a common strategy defined that we could follow.
Person B: Yes, we could define our processes so we could compare what we have in common and collaboration on systems.
A: Then we could create a plan for how to align our IT investment with business drivers (seriously, they said exactly this)
Person C: That's called enterprise architecture, you're talking about enterprise architecture.
B: No, don't say that word.
A: Yeah, what does that even mean? We looked up "enterprise" in the dictionary and it means a risk taking endeavor.

It's interesting to witness this for two reasons:
1) They've obviously encountered EA before and it left a bad taste in their mouth. This seems fairly common as a large portion of my engagements involve explaining how we aren't like those other EA guys who wasted their time and money.
2) It is an artificial term that reeks of IT speak.

As much as EA claims to be about the business and how business should drive EA, the EA organization is under the CIO/CTO in 9 out of 10 organizations (at least in the federal environment it is mandated by Clinger-Cohen). We constantly use technical jargon even when we don't think we are doing so.

Another recent anecdote I had when talking with a business steward about what the difference between a data repository and a data warehouse is:

"The data repository contains the raw data received from parters. The data is then processed with business rules applied and loaded into the data warehouse. The data warehouse has analysis and structure for the aggregate data."

Now, granted, this is to explain the arbitrary definition of data warehouse/repository that the technical group had developed. But I was trying to clear up this confusion. The business steward is a brilliant person with a PhD and everything but she said

"Sorry, I don't know what you just said."

If EA really wants to engage with the business side of the organization, it needs to stop using geeky terms like "architecture", "enterprise", "service" (in an SOAy sense), etc etc.

A final example: In the FEA Practice Guide it says "Architect, Invest, Implement".

What other practice verbs nouns as much as IT? I mean seriously, if you buy a house does your architect say "I'm going to go architect up your blueprint sir."

Anyway, the point of this post is that EA should strive to remove the IT vocabulary and talk like the rest of the business people that EA strives to be.

Labels: EA

  ¶ 8:36 PM 0 comments