This past fall the enterprise architecture community was abuzz with the news that John Zachman, who created the Zachman Framework and is the de facto father of enterprise architecture, was suing his colleague Stan Locke for $10 million. I won’t rehash those details here, but rather use this as my jumping-off point. The issue led to a lot of Zachman-certified enterprise architects worrying about the status of that certification, the continued licensing of the framework’s existing intellectual property, and the prospect of a new training course and certification program coming from Zachman’s son.

The lawsuit news also prompted more existential questions about the Enterprise Architecture framework certification marketplace as a whole. As Gartner’s Philip Allega wrote at the time: “This further weakens the perceived value of marketplace certification in EA Frameworks.”

Does it? More than one enterprise architect replied that in the real world, it’s rare that any single framework alone guides efforts. In fact, The Open Group Architecture Framework, or TOGAF, itself is a distillation of what frameworks such as Zachman and Federal Enterprise Architecture Framework (FEAF) bring to the table. Not only that, some in the community said, but certification in any framework matters less than doing the work itself. In other words, it’s experience that counts.

It’s hard to argue against the value and virtue of experience such as knowing when, where and how to apply different frameworks to enable a cohesive strategy. But, of course, it’s equally hard to ignore the fact that when enterprise architects are job-hunting, keyword-based resume searches and HR departments expect candidates to prove their enterprise architecture expertise. You can list all the real-world accomplishments you like, but you may still get overlooked in keyword searches if you can’t “prove” that credibility with specifically named certifications. Certification in frameworks — whether Zachman, TOGAF, FEAF, DODAF, ITAC (IT Architect Certification), university-designated/sponsored, or other industry- or vendor-specific — continue to play a role when you look through the job boards. 

Consider this very recent posting in the logistics industry, which illustrates that both real-world experience and specific framework expertise are important to this:

Or this one in the energy sector:

Even a casual survey of postings makes it plain (at least to me) that certifications still carry weight, both in bringing your resume to the top of the pile and in building your brand as an enterprise architect.

That said, if you’re contemplating adding your first or your fifth certification to your credentials, you may want to keep your eye on an effort by the Center for Advancement of the Enterprise Architecture Profession (CAEAP). It’s working to create an accreditation program in certifications, as well as education and training.

Does certification matter to you as an individual enterprise architect and to the profession at large? I’d love to hear why — or why not. 

In implementing enterprise architecture practices over an existing IT culture, alignment of resources is a critical step.  In dedicating resources to focus on policy and architecture and separating engineering and operations, rifts can form that cause problems with execution.

Often, established teams are separated to focus on engineering, operations, and architectural planning (or some similar permutation).  Time is initially focused on knowledge-transfer.  This leads to efforts to put in place formal rigors supporting enterprise architecture concepts like architectural reviews, a building-permit model, technical architecture standards management, etc.  While these focus areas help teams increase their depth of capabilities, they often lead to situations where de-coupled groups are no longer working as efficiently on delivery.

I have had the opportunity of driving the principle team responsible for IT Security at CA. Recently I moved my policy and planning functions into an emerging Enterprise Architecture practice and saw a skilled protégé assume the daily operational and engineering oversight. While we have been establishing formal engagement processes and mapping our interlocks for things including roadmaps, annual fiscal planning, and risk management, we have seen the shift from IT security being a one-stop shop into a divided set of teams that need to act as one in order to execute effectively.  A robust IT organization practices enterprise architecture and end-to-end operations seamlessly. The challenge is to ensure that the operational/execution organizations and the policy/planning functions communicate tightly around resourcing projects to ensure proper execution.

While there is no silver-bullet approach (one-size will not fit all IT organizations), we have found that spending time on the interlocks and addressing the possible rifts proactively and at the root-cause of issues has helped ease this transition.  While this is not a unique problem, it would be very helpful for IT organizations undergoing this kind of transformation to see suggestions on how to overcome the challenges of de-coupling EA and Execution.

What are your thoughts?  Please use the comments to chime in.

Recently I’ve been thinking about service-oriented architecture. SOA has been around long enough that it may sound like yesterday’s news. After a decade of formal SOA standards and deployments, organizations have become familiar with what it takes to deploy a SOA, along with its benefits.

Certainly, the financial services industry seems happy with the results. A recent Forrester survey found, for example, that of 80 IT executives from financial services firms around the world, close to three-quarters use SOA and business services in a significant number of business applications in a production environment, and many have plans to extend the SOA footprint in their financial services firm. Nearly 20 percent are planning or deploying SOA-based applications for quality assurance or pilot programs.

But familiarity shouldn't breed too much comfort. There’s always more to learn about any discipline, particularly one such as SOA that is closely entwined with enterprise architecture practices, given how critical such practices are to the business.

One effort that’s worth your getting more education about, for example, is the Open Group's Service-Oriented Architecture Ontology Technical Standard. Here, we’ll take look at how such an effort can make sense in your business, especially if you revise your SOA more than once per year -- making changes or updating the text, for instance.

The SOA Ontology will help you create an enterprisewide set of architecture documents if you don’t have one already, and further refine it if you already do.

SOA Ontology Is a Step to Clarity

As part of the Open Group’s vision of Boundaryless Information Flow, which aims to align IT with the business it serves, the SOA Ontology goals are to:

·         Enable clear communication between business and technical stakeholders

·         Define metadata for architectural artifacts

·         Create a model-driven SOA implementation

In a sense, the ontology is a model of models for developers of SOA-based software systems, expressed in the Web Ontology Language (OWL). It uses natural language to describe concepts and relationships, along with graphic illustrations. Specifically, it uses both XML — with a well-defined schema — and the Unified Modeling Language (UML) to model the system. UML is itself a useful ontology that is used to define whole architectures, models, and even other ontologies.

The Open Group’s SOA Ontology allows you to simultaneously define the interactions between all of the systems and services in your organization (the “big picture”), as well as the design of the individual systems and services. Because they’re often only part of overall enterprise architecture, the ability to clearly communicate the details of your SOA-based systems, their constituent components, their interactions with one another, and their usage within your overall architecture can directly contribute to the success or failure of your enterprise architecture and its implementation. The ontology allows you to clearly delineate the boundaries between SOA and the rest of your organization’s architecture.

The result of having all of the elements, relationships, sequences, policies and so on defined in OWL is a series of artifacts that can be used both visually, to “see” and discuss the SOA, as well as programmatically, to model and implement the SOA design. It’s not a stretch to think that once you accurately describe and visualize your architectural models with the SOA Ontology, you’ll be able to identify weaknesses to improve, missing pieces to fill in, and strengths to use in future projects.

Inside the SOA Ontology

As enterprise architects, you’ll want the technical details about the ontology, so here is a summary of the concepts defined by The Open Group:

The Ontology defines concepts such as system and element (or component), and relationships such as uses and represents (or “is a”), to associate them. Elements in the SOA domain include actors, tasks, services, or other concrete items such as a service bus for communication between services. Relationships describe how the system’s elements interact with one other. A task or service in the ontology associates the actors and elements within the system to describe how the system is used or interfaced with in the overall architecture.

Properties, such as does or doneBy clearly demarcate the responsibilities of the actors in the system. Diving deeper into the ontology, you define contracts, interfaces and information types to clearly state the capabilities of your system’s elements. For workflow-related systems, sequences of tasks can be defined as either a composition (where elements are built from other elements), or orchestration of elements (where elements interact more loosely). In another form of association and interaction, events define and allow for asynchronous communication within the system as well. For security, a policy is used to define rules that govern all of these interactions between elements.

Each element in the system may be a system in itself, which can be used in its more abstract form to describe composite services, or each element can be further broken down and explored using the same ontology.

This creates a system of systems where different stakeholders (business analysts, architects and developers) can dive as deep into the model as required. For example, business analysts can peruse the higher-level system definitions to ensure the entire problem domain has been addressed. Architects can take a more detailed look to determine that business needs have been met in terms of features and Service Level Agreements. Further, developers can dive deeper, examining each service’s constituent components as a road map to implementation. Finally, quality assurance can use it to ensure complete test coverage, end to end.

Visual modeling tools such as Embarcadero's Studio Architect, Troux Architect from Troux Technologies and Visual Modeling Platform from Sparx Systems all help drive architecture from idea to reality. The resulting artifacts take shape as UML diagrams, entity relationship models (ERM), and other object models. Some tools, such as IBM's Rational Rose, can even generate code for multiple programming languages.

If you want to learn more, take a look at the following resources:

·         The Open Group SOA definition

·         The Open Group’s Service-Oriented Architecture Ontology

·         Web Ontology Language (OWL):

In my last blog I discussed where the enterprise architect function typically resides within an organization and what the enterprise architect can do to be successful within those structures. Today, I thought it would be interesting to consider what the enterprise architect needs to BE in order to carry out the EA role in the organization.

In other words, what besides the technical skills are the essential characteristics and cumulative experiences that make an enterprise architect able to handle the challenges of the role? To that end, I present some ideas—in acrostic form-- about what characteristics define the type of person likely to take this job, and love it: 

A: Agile. An enterprise architect creates an agile organization — maybe even with the help of the Agile Architecture method! But by agile in this context, I mean an inherent personality trait, the ability to move from business-speak one minute to geek-speak the next, for instance, or being quick to leverage the briefly exposed soft spot of a line-of-business manager that can be played to so as to build project buy-in. 

R: Range. An enterprise architect, it almost goes without saying, can’t be solely invested in creating complex technical solutions and structured documents. That person’s range needs to extend to understanding the business. Dare I say, even to loving the industry he or she is in. And loving it enough to dig in beyond the systems requirements that drive retail supply-chain activities, for instance. And enough to stay abreast of overall industry trends and directions, emerging global challenges in the vertical sector, and the company’s strengths and weaknesses within these contexts. 

C: Communicative. An enterprise architect cannot be the guy or gal off in the walled garden creating models and diagrams that are to be implemented by faceless individuals. He or she is the great communicator who facilitates IT and business alignment by facilitating and fostering IT and business interactions. And the enterprise architect must remember that communication is a two-way street: He or she must help lead the discussion as well as patiently LISTEN to the viewpoints of colleagues, customers, and partners – even when the conversation seems redundant or the answer seems obvious.

H: Holistic. An enterprise architect thinks holistically, about system design, problem solving, technical- and business-domain structures and processes … and the people who engage with them.

I: Innovative. An enterprise architect knows that the work is about more than helping the business do what it always has done, but better. For example, it’s about exploiting opportunities to fundamentally change workflows instead of simply improving their execution. 

T: Transformative.  An enterprise architect excels both at driving the short-term steps to achieve quick wins for improving tactical operations and fitting them into a strategic vision for long-term business transformation.

E: Experienced. An enterprise architect needs to have experience at multiple levels. There’s the technical aspect of experience, of course, with skills honed in application development and maintenance, business requirements engineering, and infrastructure planning and support. But also the architect needs to be experienced in the art of politicking — negotiation, compromise, persuasion and consensus-building all come into play.

C: Conflict Confronter. To extend that thought about politics, the enterprise architect is aware that others in the organization are going to be invested in exploring other technologies or other ways of doing things from what the architectural direction is. And he or she knows one can’t be timid in dealing with that. Nice, yes; timid, no.

T: Techno-freethinker. As discussed in our recent article, Enterprise Architecture: Strategize Before You Modernize, the enterprise architect has to come to the table with no preconceived notions of or allegiances to specific technologies or technology providers. You can’t lead — as you must — if your mindset is narrow, rather than open to all options.

What other qualities do you see as critical to the character of an enterprise architect? We’d love to hear your thoughts!

The new year is well under way. How about your review of your cloud architecture strategy?

As more mission-critical services move to the cloud, this is one resolution that shouldn’t be pushed out (you know, the way the diet and exercise ones usually are ...). That’s especially true now that cloud platform services are raising the stakes when it comes to what you can expect from embracing the cloud as part of your architecture.

Here are some questions and ideas to incorporate into your own review plans:    

·         Are you realizing value from turnkey, integrated services?

An informal analysis of Fortune 100 companies shows that only two weren't using application cloud-based services as of October 2009, according to Stanford University lecturer Timothy Chou (see here for a link to the document). That number may well be zero now, because the benefits from cloud computing have become even clearer since this document was composed.

The next phase of the cloud looks as if it’s going to be about vendors providing added features beyond the raw services you get with Amazon, Google and Oracle clouds. You might be leaving some value on the table if you don’t at least explore how some of these cloud platform solutions might fit into your overall architecture strategy.

For instance, turnkey solutions built on top of some of these cloud compute platforms offer complete stacks with many features built in. Services such as CA Technologies’ 3Tera, for instance, that reuse the Amazon EC2 cloud add on capabilities for distributed applications and optimizations for transactional and I/O intensive workloads. Cloudera is another source for full stacks of integrated cloud services.

Solutions such as these are designed to eliminate tight coupling between hardware and software, which allows you to more easily change your cloud application compositions and the business processes built from them.

·         Are you benefiting from built-in security and availability capabilities?

These latest cloud platforms offer up-to-date firewalls, load balancers and other required network technology to support high-availability and uptime (even in the face of denial-of-service attacks). In addition to your application logic components, ensuring redundancy at all layers (including the network and storage services) reduces the risk of downtime in your cloud-based architecture. So, using such platforms means that your services will inherit security, reliability and monitoring at a much lower price point than doing it yourself.

But while cloud platform solutions typically offer the monitoring, self-healing and dynamic network optimizations required to improve security and reliability, it’s also important to review whether the architecture takes advantage of physical isolation, IP address enforcement and data isolation. Pure virtualization-based solutions simply can’t, or just don’t, offer all of these required security features. Consider whether a cloud platform offers the right balance between virtualization and physical isolation – just as you would for your in-house architecture.

·         Can you create dynamic business processes?

Cloud services such as CA Technologies’ 3Tera’s AppLogic allow you to break your processes down into individual logic and data units that can be more easily deployed to the cloud, and then quickly be recomposed and scaled to handle even your most complex applications.

This removes issues involved with managing these compositions yourself, such as the business disruptions that are often experienced when reconfiguring and deploying software on your own hardware. The disruptions you experience in-house are often replicated in the ether when entire apps or services are tossed over to the cloud without regard to reuse considerations.

Most important, by removing the configurations otherwise required, these cloud platforms enable you to more quickly deploy and test new services for your enterprise or your customers. The result is a more nimble and reliable IT organization, with direct benefits in terms of cost savings and customer satisfaction.

·         How easily is testing accomplished?

Using cloud management interfaces with GUIs that enforce predefined business process workflows, and well-defined application program interfaces (APIs) such as the Federated Web Service API and other WS (Web Services) standards from bodies such as OASIS, results in much easier testing of composite cloud applications. Providing these interfaces within your organization, and among other vendors, eliminates disruption to your applications due to unexpected changes. These interfaces ensure that only tested and proven cloud components are assembled, with proper data sets and formats, such as JavaScript Object Notation (JSON), into new composite applications that inherit the quality of their constituent services.

Beyond quality assurance, cloud testing platforms such as SOASTA [soasta.com] offer transparency about the capacity of your cloud services and composite applications. Knowing — through proven testing practices — that your application can meet the demands of your users, even with unexpected spikes and surges in activity, offers the level of confidence required for your mission-critical applications.

·         Are you staying in touch with industry efforts?

As a final note, the Stevens Institute of Technology, located in Hoboken, N.J., has started the Cloud Computing Consortium to work on collaboration and standardization across cloud providers and vendors across the industry. The consortium focuses on typical enterprise architecture issues, such as change management, security and other business value propositions with cloud platforms and road maps.

The consortium and its members aim to improve the quality, interoperability and value of the cloud through sharing best practices, defining standards and helping industry leaders collaborate.

What better way to ensure that your cloud strategy is on track than to collaborate with your peers and understand what’s working for them?