Skip navigation
Twitter   Follow us  •   Share   Share    Become a member

Smart Architect

2 Posts tagged with the the_open_group tag
0

Did you hear the one about the clinical psychologist who became an enterprise architect? No? Well, if this were a joke, the punchline might be that the poor guy’s spending more time in therapy now than ever before. Only this time he’s on the other end of the couch, trying to work through the pain of resistance and rejection by senior business people who tell him that they understand architecture matters but they just don’t have time for it.


As it happens, MIT’s  Jeanne Ross, one of the premier researchers in the field of enterprise architecture and IT, actually did once meet an architect who started out as a clinical psychologist — and he told her that his earlier training really helped him in his current role. Point being that much of what an EA does is as much the art of persuasion as the science of integrating data and processes, as much about gaining insight into people’s hot buttons as it is about bringing standardization into the organization.

 

As Ross, Director and Principal Research Scientist at the Center for Information Systems Research, explains, they have to “know how to get buy-in for something people don’t think they have time for and think that you [the enterprise architect] will take care of for them.” The problem with that is that while architects can do a lot, they can’t have a positive impact all by themselves. Says Ross, “I would urge architects to recognize that their success totally depends on other people’s behaviors, and thus they can never give up working on other people’s behaviors.” (Are you seeing the psychology connection now?)


Ross, who gave a keynote presentation on how enterprise architects can design business success at The Open Group Conference in San Francisco in January, says that architects don’t always recognize that not everyone necessarily gets what it means to have enterprise processes and what it takes to get enterprise data. That’s not to say that their business peers aren’t logical and smart people, but, Ross says, “they’re thinking in silos and silo-thinking works against all that architecture tries to do.”


To counter this, Ross says you need to be prepared to go against some natural inclinations of what you think you should be spending all your time doing — focusing on design — and what you actually should be spending time doing. The great architects, she says, are in the field, spending time with the people designing processes, for instance, or heading up call centers. They’re stepping back from the big-picture view of creating enterprise value and instead first asking themselves who it is in the organization that is best positioned to make things happen — “Who wants something in the worst way that will be better accomplished if it’s well-architected,” she says. So, your plan should be to get them to recognize that the best way forward is to think end-to-end, about integrated processes or shared data. “Invariably there’s some piece that some people will get,” she says. And those movers and shakers become your champions. 


Being proactive with the business side also means that chief architects likely will find themselves in the position of constantly forcing more clarity around the operational decisions of senior executives that, frankly, in many cases aren’t very clear. Their desire to take steps to transform the business, which includes transforming the architecture, is real but doesn’t always take into account long-term impact and the metrics that will be used to gauge it. “Architecture comes down fundamentally to two things: standardization and integration. Many senior executives think about neither in the long term, and because they don’t think of it, in a way architecture is impossible,” Ross says. “If a company has made no decision on what to integrate and standardize, you can’t go forward.”


The job, then, is to make it plain that integration and standardization will be in vain unless the business understands the real commitment this entails, and the impact that it will have on the company in terms of what it can and can’t do going forward. “A lot of companies haven’t gone the step beyond to talk about how we operate, how people’s jobs would change, about how their relationships with customers would change,” she explains. “Architects have to articulate that if I do this, then that is the result. You can help them understand the implications of their decisions.”


In other words, you have more leverage than you may think. Ross says that in her experience working with companies that have succeeded in IT-enabled transformation initiatives, the CIOs had good architects working with them. As one example, the Commonwealth Bank of Australia began a transformation in 2006 focused on meeting its customers’ need to be treated as one entity across all the divisions they dealt with. The inclination of many architects, she says, would have been to do a major overhaul, consisting of ripping out the legacy system and putting in a new banking engine, but here they focused on getting to the big impact through smaller initiatives with more immediate results. The bank began with doing just enough of an architecture revision on the back end to deliver a friendlier Internet interface to the customer. “They said, let’s fix just what we need to fix [to create] a single interface for the customer so it looks better in the back end than it is. That is brilliant,” she says. A few years later, having met their desired operational metrics — operational costs as a percentage of revenue and customer satisfaction — they’re ready to take on the banking engine itself.

 

Bottom line: “In companies where leaders have religion about architecture, it has a huge impact, and individual architects have a huge impact,” says Ross.


To be successful at proselytizing requires knowing your audience well, of course. To gain that insight, perhaps it wouldn’t be a bad idea to sign up for a Psych 101 refresher online, or reflecting on a couch before diving into the EA challenge.

0

Is it possible to replace a living, breathing enterprise architect with a do-it-yourself architecture kit? How about with blueprints, formulas or other design templates?

 

 

Companies have been known to take stabs at it, and not without success. The Java BluePrints series of documents in the 1990s enabled bare bones, agile teams at small start-ups to build the online economy. Today, Oracle maintains them, while Microsoft offers its own set of blueprints, the Software Factory methodology, whose concept is to apply working patterns of software architecture, development, testing and release to sets of problems that cookie-cutter development teams can solve. CA Technologies offers blue-print papers and videos in the areas of data modeling and architecture, as well as virtualization and the cloud. And other vendors also have their own approaches.

 

 

These are all useful goodies for a number of reasons. But their usefulness increases, I believe, when an enterprise architect is onboard to oversee efforts to deploy these tools to automate software architecture and design processes. What the architect brings to the picture is everything from an understanding of time to market, cost and ROI considerations, to enterprisewide skill sets and global deployment experience. And let’s not forget what enterprise architects know about security, creating flexibility for tomorrow's desktops and mobile devices, and accommodating the growing desire to be green (e.g., energy and heat efficiency, recycling and so on). This all leads me to believe that a do-it-yourself architecture strategy probably won't work for all cases, all problems and all companies.

 

 

 

Patterns: The Enterprise Architect's Ornaments

 

One important thing that do-it-yourself kits or blueprints may not always account for are architectural patterns. If an enterprise architect wore medals, they would take the form of architectural patterns he or she helped define. An architecture pattern is a schema for a software system and its overall structure, whereas a design pattern is a more detailed, specific refinement that outlines deeper relationships between components. The Open Group has been overseeing work on standards for architecture patterns as part of The Open Group Architecture Framework initiative. The Object Management Group (OMG) has also done some work here. Together, they’ve defined patterns for service-oriented architecture, event-driven architecture, model-driven architecture, resource-oriented architecture, directory services, security, transactions and the list goes on.

 

 

According to the Open Group, patterns are a way of putting the building blocks of architecture into context so that they can be reused and applied in the right ways. For instance, patterns should clearly define how and when to use the building blocks, the trade-offs involved, and other related caveats or prerequisites. For each pattern, it’s recommended that you specify at least the following:

 

  • The problem: when to apply the pattern
  • Context: preconditions for the pattern, and other assumptions (i.e., multi-core servers)
  • Constraints: considerations in terms of security, cost, efficiency, performance, bandwidth, power consumption, openness, portability and so on, as well as how trade-offs are made between them
  • Proposed solution: in terms of implementation and deployment
  • Example: where possible, provide a real-world example of the pattern at work
  • Related patterns: often patterns build on, or work in conjunction with, other patterns
  • Alternatives: a single solution is rarely the only solution; list alternatives and when to choose one over the other.

 

 

 

Some organizations have made quite a bit of progress defining architectural patterns that apply to specific problem domains. For example, the Open Geospatial Consortium , in conjunction with the OMG, has defined patterns that actually apply to a broader set of problems. These include patterns for geo-data storage and access, generic SOA and Web services, interoperability through data standards, data-binding models and so on. Martin Fowler’s book, Analysis Patterns: Reusable Object Models, and Fowler’s site are also good resources for more information on the subject.

 

 

 

Software Architecture with Math

 

If we could use mathematics to prove the value of the architectural patterns that enterprise architects define before the coding process begins, the case for their oversight of do-it-yourself tools gets even stronger. Other engineering disciplines, after all, use math extensively during the design phase, including electrical engineering, aeronautical engineering, mechanical engineering and so on. It’s the math that gives engineers like my father the confidence that his designs will fly — literally! Beyond basic math used to calculate memory requirements, server scale and database sizes, I’m not aware of anyone using math extensively in practice to define or at least prove their enterprise architectures, though. So if you’re actually doing this, or know anyone who is, I’d love to hear about it.

 

 

But I digress. What it comes down to is this question: Even if you could always rely solely on kits and patterns to the exclusion of enterprise architects, should you always? I think not — or at least, not if you care about customer satisfaction. It takes careful consideration to craft solutions that are not only profitable, but also make our customers continually happy (which, by the way, goes a long way toward driving profits).

 

 

So I think our jobs are still safe, and that we should instead embrace patterns and measurable processes. In fact, being part of the continuing contribution to the definition of patterns and other verification processes can help ensure our long-term success.

 

 

 

 



We encourage your feedback. Reach out via the "Contact the Editor" and "Contact the Concierge" services for any needs, questions or comments. We look forward to serving you!

Paula Klein, Smart Enterprise Exchange Editor
e-mail

Ellen Lalier, Smart Enterprise Exchange Concierge
e-mail
phone 516-562-5727; fax 516-562-5466