Enterprise Architecture IS Arbitrary

Just finished reading Yes, “Enterprise Architecture Is Relative” BUT It Is Not Arbitrary"
and it was a nice article, but I politely disagree with Zman that "architecture is not arbitrary".

Lock 10 architects in 10 separate rooms; provide them all an identical copy of the same business, technical, process, and system requirements; have them design an architecture under the same rules and perspectives; and I guarantee your result will be 10 different architectures of varying degrees. Maybe my opinion is biased because I come from a Software background, but I often think Enterprise Architecture is an Art that is trying to apply a Science. No 2 architectures are identical. No 2 interpretations of how an Architecture should look like are identical. No 2 Architects think alike. Often times, Architecture is the art of compromise because rarely will you get to 2 architects to agree on the final architecture. Compromise is really hard for us, because we are traditionally very stubborn people! I've met many an architect whose ego is bigger than the Internet, and thinks he could teach a thing or 2 to Socrates. We don't like to be told we are wrong, especially when we develop a "work of art".

Maybe a better statement can be "architecture tries to make the design non arbitrary". With good architecture principles, patterns, frameworks, rules, constraints, standards, policies, procedures, and approach, the design becomes a simplistic exercise with little left to judgement, error, and becomes more a commoditized task. This is what I think architecture truly strives for-- making everything downstream trivial. Architecture lays the foundation for the remaining pieces to snap in very easily without much variance. Success is when the blueprint is followed according to plan!

The article continues to articulate how industry standards have played a role in making architecture non-arbitrary. This makes sense in certain vertical industries cited in the article such as airplane manufacturing, nuclear power plants, developing the Space Shuttle. However, it doesn't make sense in many commercial corporations whose architecture is centered and largely dependent on enterprise software .

Think about it-- Building an airplanes for Boeing or a nuclear reactor has very strict standards, specifications, and processes with little to no variance. However, building software has tons of variance and therefore industry standards are rarely adopted religiously in software implementation (unless you are in some thees industries mentioned above). There are some very simple reasons for this dynamic:

• Qualifications for building software are low. Low barrier to entry, commoditized work force, easy to learn software programming skills.
• QA requirements are much lower. Often times, it's "just enough QA" and many corners are cut and sacrificed so not to slow down the market plan.
  
• Time to Market patience is low. Software is expected to get deployed before its truly ready (and bugs are well known). Rapid is the name of the game, especially in today's economy.
  

Ultimately, software does have great industry standards, but I've found most commercial companies use the industry standards as guidance, not a text book. They leverage it as a good starting point, but build their own internal standards and proprietary architecture. And, these internal standards are often arbitrary in nature.

Healthcare IT to benefit greatly from new Bill

Whether you are an elephant or donkey, something we can all agree on is that our health care system is currently not well-integrated from an Information Technology perspective. Health care is filled with expensive data redundancies, outdated and non-timely information, slow processes, and yes even bad and incorrect data. Well, if your in the business of integrating these systems, processes, and institutions, your in luck because the new health care bill is full of funding for electronic medical integration, and is said to "buoy last years $20M health care IT stimulus". Wow. Health care IT innovation may finally be getting its proverbial kick in the butt. This is a good article that provides a nice overview: http://tinyurl.com/yzzfp95 . If your in the market of integrating these systems, go hire a good proposal and grant writer because there will be a lot of opportunities to win business with the government. And, if we truly deliver on the promises of an efficient Health care system with Electronic Medical Records (EMR), we the citizens will benefit as well in having better visibility into our records, faster medical processing, less mistakes, reduced costs, etc. Healthcare IT has always lagged from its corporate peers in updating its IT systems, but now we can expect to see a lot of catch-up...the only question is at what cost? Maybe this is something Republicans and Democrats can agree on?

Healthcare Regulation requires Business Agility

Whether you agree with the US's recent bill on health care reform or not, it is clear that businesses will need to be agile in order to comply with the new forthcoming regulations they must comply with. There are always byproducts of regulation (i.e. secondary markets) and I have to think SOA will be one of the beneficiaries from organizations having to be flexible enough to comply with new regulations. How fast can a business change without disrupting current business operations and without impacting new growth opportunities? That is a scary question to many organizations and sends shivers down CIO's backs. A lot of organizations either don't have the IT flexibility to change with these new demands on their business, or can only adapt through manual, non-automated processes (such as hiring more business analysts to collect and disseminate the corporate information-- see "swivel chair integration"). They might be able to throw an army at the problem, but that is not only resource expensive, but risky in waiting until the problem bubbles to the top.

SOA is premised on the philosophy of "designing for change". The goal is that when business requirements change, IT can rapidly make adjustments to support the business demands because the IT systems are designed, documented, and impact transparent to allow IT to quickly adapt to new requirements. Businesses are always changing-- new business opportunities, new channels (see "Internet"), new partnerships, Mergers and Acquisitions, or in this case NEW REGULATION. The challenge is IT can't keep up with their current architecture and IT envirnements, let alone support all this change! Unfortunately, the whole company suffers from lack of agility! I would love to see a poll of Fortune 2,000 companies on how quickly their IT departments were able to adapt and change when Sarbanes Oxley regulations were enforced upon them? My bet is this would be measured in years, not months, and there are still quite a few companies struggling to adopt Sarbanes today.

Now that we know businesses will need to comply with new health care reporting, financing, personnel, operations, and taxes, how many are equipped to comply with the new reform? Will this be Sarbanes Part 2 and will IT departments be scrambling to change their tightly interwoven legacy systems, CIO's hiring more business analysts for more swivel chair integration, companies being fined for lack of compliance, or even worse making the front page of the Newspaper? How about more regulation coming down the pipe? If there is one constant we do know, is that the business will always change. Regulation is never a 1 and done initiative.

There will always be new regulations enacted on companies, so I advocate that businesses bite the bullet now and invest in agility by considering how SOA approaches can help them solve these problems, limit their impact from required changes, and prevent risk. The payoff from SOA investment will easily be achieved in this case, simply by reducing the cost of regulation compliance (lower resource cost) and "future proofing" the organiztion for adapting to new regulations on the horizon. Let's not forget, SOA-driven agility also opens doors for new revenue opportunities too-- another topic for another day. The early bird gets the worm, so be proactive instead of reactive by architecting your IT environment to meet these important business needs!