Monthly Archives: June 2009

Architecture Frameworks Don’t Make Architects

So, I was about to blog on this topic when up comes a Tweet from Ron Schmelzer (@rschmelzer) over at ZapThink, “Question for the tweeple: do Federal EA Frameworks matter? And how do they stack up against non-Federal EA Frameworks? Do Frameworks matter?” Talk about synergies! Obviously, the value of EA frameworks is being questioned by many individuals.

This morning I posted the following comment on the #CAEAP website

“I see there are work tracks that focus on ‘Enterprise Architecture Professional Learning Framework, value to the practitioner’. I think it would be interesting to consider here a move away from a focus on frameworks and a move toward apprenticeship. My personal experience is that frameworks don’t help individuals become architects, it just provides a tools for organization of artifacts. Yet, I believe the industry believes that these frameworks (DoDAF, TOGAF, FEAF, PEAF, Zachman) help non-architects do an architect’s job.”

In my experience, all these frameworks provide a way to think about and organize the artifacts that are part of enterprise architecture, but a framework cannot make you an architect. Additionally, these frameworks provide a means of breaking down the work effort to collect these artifacts, which can be done by non-architects. But, in the end, all these artifacts need to be analyzed against a set of business goals, which then leads to the production of a design that aligns technological direction with the mission of the business.

Which brings up an interesting question, “who is using the framework?” In some cases, the framework has become a bureaucratic milestone on the way to approval. It doesn’t tell anyone who isn’t an EA anything more than what’s been collected about the current environment. There certainly is no way to ensure that the entire current environment is even fully represented by way of the artifacts that are represented. It’s merely a checkmark on some bean counter’s checklist before releasing funds.

If an EA is using these tools, more often than not they are stymied by the lack of support for emerging architectural approaches. As an exercise, try to find a standard way to capture an SOA design using one of the various EA framework approaches. Sure, people are hard at work trying to retrofit these standards to support emerging architectural methodologies, but these approaches take time and are often years behind the industry.

Most importantly is that enterprise architecture frameworks are designed to be tools. A chisel in the hand of a sculptor will yield a work of art, but in the hands of an amateur yields a pile of rubble. The same is true for any of these frameworks. We need to focus on the creation of architects. I believe the IT industry has been remiss in this effort. Sure, they pay for a few conferences, but architecture is something that is culled over time and based on seeing mass of systems being designed and built. I believe instead of certifications, we should focus on apprenticeships. The resume of an architect should read,

“Studied under XYZ from 2004-2006. XYZ has been responsible for … at … While studying under XYZ I was subject to delivery of the following types of systems.”

While I’m on the subject, I believe the same is true for cybersecurity experts.

Apprenticeship is a lost art in the world, which is a shame. Our desperate need for resources today has limited our long term vision of what the IT industry needs to thrive 20, 40 or 100 years from now. Business believes systems can be designed like a McDonald’s hamburger and that developers and architects are nothing more than the lettuce station and the fry station.

Why do we consistently see headlines, such as “SOA Is Dead”, “EAI Is Dead”? It’s simple, because all these things are really complex and you can’t approach them with an assembly line mentality. Forget Henry Ford already, look at Detroit, learn a lesson people! Focus on developing quality, which means selecting those individuals capable of being architects and supporting them through apprenticeship programs. Moreover, support the creation and execution of apprenticeship programs in your organization.

Business’ Abuse of IT People

I just want to give a shout-out to all those IT people working their butts off everyday and taking crap for it.

Over the years I've been witness to IT people being abused by the business for not delivering, when in fact, it's the business putting IT in a "no win" position.

One one hand, the business expects IT to make sure that computing resources are used effectively and that costs are kept in check. This includes application procurement, development and computing infrastructure. However, the business also expects IT to not stand in their way when they want to get something done.

Question for the business, "how do you expect IT to keep costs in check and optimize resources when you demand the ability to do whatever you want whenever you want using whatever tools and people you want?"

Look, over the years, I've been a big supporter of IT needing to operating in "business time" and I still believe it is an important goal. That said, one of the major hindrances to this is the lack of adherence to standards where they exist and the end-runs around IT when the business doesn't like the choices IT makes.

IT, this doesn't mean you're off the hook to accommodate the business. Remember, we're here to support he business, not the other way around. You need to pick standards that make sense to the majority of users. Make sure you have done effective enterprise architecture design before making decisions on products and standards; especially products. Don't be swayed by vendors promises. Make sure the business agrees to the value proposition.

The Reason SOA Isn’t Delivering Sustainable Software

Wow, to read the positive reviews of SOA and what it’s doing for the IT industry, one would be likely to believe that there’s serious transformation occurring because of this architectural approach. Well, the truth is, implementing an SOA design such that real loose-coupling is achieved and that a service does not share a common bond with any other service down to its roots in persistence and all the way up to its consumers, using today’s technology mix, is complex, clumsy and fraught with sandtraps.

I was discussing this topic with a friend the other day who is a big advocate of “just focus on the work and stop worrying about the ideology”. I know this person knows how to develop maintainable and sustainable solutions, so when he says “just do it,” I know that implies just do it using common, agreed upon best practices for developing agile software solutions. So, we kept beating about this concept of sustainability and we both finally agreed upon that the key is focusing on understanding the business. This means sustainability comes from analyzing from the top down, not the bottom up as bottom up results in tactical solutions that do not conform to the needs of the business over time.

I know this last statement is controversial. After all, it’s difficult to accept that if you develop using good component-oriented approaches that you can’t retrofit today’s bottom up for tomorrow’s bottom up. But, the fact is that bottom up expresses the “how” not the “why” and the “how” is limited by the subjective reality of the person(s) providing the information. However, truly understanding the business allows the architect to design to an objective goal that can be presented in whatever subjective ways is needed today.

But, let’s revisit my opening premise that implementing SOA designs today is complex, clumsy and fraught with sandtraps. I believe the complexity stems from the fact that SOA works best and is most easily aligned with loose-coupling when services are stateless. This means that the service retains no knowledge of the consumer prior to or post usage and has no assumed context of the consumer.

Moreover, a service should operate in a deterministic manner and the consumer should make no assumptions that the service will operate differently based on same context. Most importantly, if any part of the implementation is implicitly linked to any other service’s or application’s implementation, then it may not maintain the ability to switch contexts as needed based on the consumer.

In many cases, statelessness is in direct opposition to the goals of business applications, which are rich in user context and assumptions of their environment. Reporting, security and governance are excellent examples of features that are hindered by moving to a loosely-coupled services architecture and, if implemented in a way that leans too heavily toward one particular application’s requirements, limits the service’s ability to operate in multiple application contexts.

For example, if a service uses a single database table that has relationships with other tables (e.g. foreign keys), and the service has no use for the data in those related tables, but yet the database is going to enforce data integrity when this one table is operated upon, thus forcing the service to be cognizant of those relationships, then loose coupling is broken simply based on the virtue that a consumer is forced to be aware of information that is outside of the scope of the service.

Additionally, there has been a strong emphasis on reuse with regard to SOA, to the point where reuse has become the single, determining factor for defining a service. However, reuse is a completely orthogonal issue to SOA. Reuse is driven by two factors, levels of specialization and interface. Low levels of specialization will drive reuse, however, high-levels of specialization do not necessarily invalidate a service design—it just makes it less reusable. An interface is merely the entry point for communication. Thus, we can create reusable components that cannot operate without the consumer’s explicit knowledge of other areas of the system, for example, a program ID, and because of these constraints disqualify it from being loosely-coupled, and hence, not a service in the sense of SOA.

I believe if you review many of the systems that today call themselves SOA you will most likely find service-enabled applications comprised of reusable software components and Web Service interfaces. Because many of today’s SOA platforms do not yet provide the necessary means to really enable true loose-coupling without sacrificing things like data integrity across services, implementing SOA designs today often requires concessions that make the resulting service less sustainable.