Archive for the ‘Enterprise Architecture’ Category

OTN Podcast on EA Communication

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

I participated on a panel discussion on communication and enterprise architecture, hosted by Bob Rhubart of Oracle. Part one is now posted on Oracle’s Technology Network, with parts 2 and 3 to follow soon.

Governance Technology and Portfolio Management

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

David Linthicum continued the conversation around design-time governance in cloud computing over at his InfoWorld blog. In it, he quoted my previous post, even though he chose to continue to use the design-time moniker. At least he quoted the paragraph where I state that I don’t like that term. He went on to state that I was “arguing for the notion of policy design,” which was certainly part of what I had to say, but definitely not the whole message. Finally, Dave made this statement:

The core issue that I have is with the real value of the technology, which just does not seem to be there. The fact is, you don’t need design-time service governance technology to define and define service policies.

Let’s first discuss the policy design comment. Dave is correct that I’m an advocate for policy-based service interactions. A service contract should be a collection of policies, most if not all of which will be focused on run-time interactions and can be enforced by run-time infrastructure. Taking a step backward, though, policy design is really a misnomer. I don’t think anyone really “designs” policies, they define them. Furthermore, the bulk of the definition that is required is probably just tweaking of the parameters in a template.

Now, moving to Dave’s second comment, he made it very clear that he was talking about governance technology, not the actual governance processes. Speaking from a technology perspective, I’ll agree that for policy management, which includes policy definition, all of the work is done through the management console of the run-time enforcement infrastructure. There are challenges with separation of concerns, since many tools are designed with a single administration team in mind (e.g. can your security people adjust security policies across services while your operations staff adjust resources consumption while your development team handles versioning, all without having the ability to step on each other’s toes or do things they’re not allowed to do?). Despite this, however, the tooling is very adequate for the vast majority (certainly better than 80-90% in my opinion) of enterprise use cases.

The final comment from me on this subject, however, gets back to my original post. Your SOA governance effort involves more than policy management and run-time interactions. Outside of run-time, the governance efforts has the closest ties to portfolio management efforts. How are you making your decisions on what to build and what to buy, whether provided as SaaS or in house? Certainly there is still a play for technology that support these efforts. The challenge, however, is that processes that support portfolio management activities vary widely from organization, so beyond a repository with a 80% complete schema for the service domain, there’s a lot of risk in trying to create tools to support it and be successful. How many companies actually practice systemic portfolio management versus “fire-drill” portfolio management, where a “portfolio” is produced on a once-a-year (or some other interval) basis in response to some event, and then ignored for the rest of the time, only to be rebuilt when the next drill occurs. Until these processes are more systemic, governance tools are going to continue to be add-ons to other more mature suites. SOA technologies tried to tie things to the run-time world. EA tools, on the other hand, are certainly moving beyond EA, and into the world of “ERP for IT” for lack of a better term. These tools won’t take over all corporate IT departments in the next 5 years, but I do think we’ll see increased utilization as IT continues its trend toward being a strategic advisor and manager of IT assets, and away from being the “sole provider.”

Governance Needs for Cloud Services

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

David Linthicum started a debate when he posted a blog with the attention grabbing headline of “Cloud computing will kill these 3 technologies.” One of the technologies listed was “design-time service governance.” This led to a response from K. Scott Morrison, CTO and Chief Architect at Layer 7, as well as a forum debate over at eBizQ. I added my own comments both to Scott’s post, as well the eBizQ forum, and thought I’d post my thoughts here.

First, there’s no doubt that the run-time governance space is important to cloud computing. Clearly, a service provider needs to have some form of gateway (logical or physical) that requests are channeled through to provide centralized capabilities like security, billing, metering, traffic shaping, etc. I’d also advocate that it makes sense for a service consumer to have an outgoing gateway, as well. If you are leveraging multiple external service providers, centralizing functions such as digital signatures, identity management, transformations, etc. makes a lot of sense. On top of that, there is no standard way of metering and billing usage yet, so having your own gateway where you can record your own view of service utilization and make sure that it’s line with the what the provider is seeing is a good thing.

The real problem with Dave’s statement is the notion that design-time governance is only concerned with service design and development. That’s simply not true. In my book, I deliberately avoided this term, and instead opted for three timeframes of governance: pre-project, project, and run-time. There’s a lot more that goes on before run-time than design, and these activities still need to be governed. It is true that if you’re leveraging an external provider, you don’t have any need to govern the development practices. You do, however, still need to govern:

  • The processes that led to the decision of what provider to use.
  • The processes that define the service contract between you and the provider, both the functional interface and the non-functional aspects.
  • The processes executed when you add additional consumers at your organization of externally provided services.

For example, how is the company deciding what service provider to use? How is the company making sure decisions by multiple groups for similar capabilities are in line with company principles? How is the company making sure that interoperability and security needs are properly addressed, rather than being left at the whim of what the provider dictates? What happens when a second consumer starts using the service, yet the bills were being sent to the first consumer? Does the providers service model align with the company’s desired service model? Does the provider’s functional interface create undue transformation and integration work for the company? These are all governance issues that do not go away when you switch to IaaS, SaaS, or PaaS. You will need to ensure that your teams are aware of the contracts in place, and don’t start sending service requests without being properly onboarded into the contractual relationship. Your internal allocation of charges takes multiple consumers into account, if necessary. All of these must happen before the first requests are sent in production, so the notion that run-time governance is the only governance concern in a cloud computing scenario is simply not true.

A final point I’m adding on after some conversation with Lori MacVittie of F5 on Twitter. Let’s not forget that someone still needs to build and provide these services. If you’re a service provider, clearly, you still have technical, design-time governance needs in addition to everything else discussed earlier.

IT Needs To Be More Advisory

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

Sometimes a simple message can be the most powerful. In a recent discussion on a SOA Consortium phone call, I made the comment that IT needs to shift its mentality from provider to advisor. I hope that most people read this and view it as completely obvious, but recognizing the fact and actually executing against it are two different stories.

Let’s look at two trends that I think are pretty hard to argue against in most corporate IT organizations. The first trend is to build less stuff. Building less means that we’re either reusing stuff we already have, or acquiring stuff from some other source and configuring (not customizing) it to meet our needs. This could be free stuff, COTS, SaaS, etc. The point is, there is no software development required.

The second trend can be summed up as buy fewer (none) servers. Virtualization, data center consolidation/elimination, and cloud computing all have ties back to this trend, but the end result is that no one wants to build new data centers unless data centers are your business.

So, if you accept these trends as real, this means that IT isn’t providing applications and IT isn’t providing infrastructure. Then what is IT providing? I would argue that rather than looking for something new to “provide,” IT needs to change its fundamental thinking from provider to advisor or be at risk of becoming irrelevant.

Am I simply stating the obvious? Well, to some extent, I hope so. What should also be obvious, however, is that this change in role at an organizational level won’t happen by accident. While an individual may be able to do this, redefining an entire organization around the concept is a different story. A provider typically needs to only understand their side of the equation, that is, what they’re providing. If you’re a software developer, you understand software development, and you sit back and wait for someone to give you a software development task. Often times, the provider may establish some set offerings, and it’s up to the consumer to decide if those offerings meet their needs or not. An advisor, on the other hand, must understand both sides of the problem: the needs of the consumer and the offerings of the provider.

To illustrate this, take an example from the world of financial services. A broker may simply be someone you call up and say, “Buy 100 shares of APPL at no more than $200.” They are a provider of stock transaction services. A financial advisor on the other hand, should be asking about what your needs are, and matching those against the various financial offerings they have at their disposal. If they don’t understand client needs or if they don’t understand the financial offerings, you’re at risk of getting something sub-optimal.

IT needs to shift from being the technology provider to the technology advisor. Will people outside of IT continue to hand-pick technology solutions without the right breadth of knowledge? Sure, just as people today go out and buy some stock without proper thought of whether that’s really the right investment for them or just what everyone else is doing. The value add that IT needs to offer is the same that financial consultants do. We provide significantly better depth of understanding of the technology domains, along with the right amount of understanding of the business domains of our companies to advise the organization on technology decisions. For the non-IT worker that loves technology, it should be seen as validation of their efforts (not a roadblock).

The final message on all of this, however, is that I believe architecture plays a critical role. To actually build an advisory organization, you must categorize both the technology and the business into manageable domains where people can build expertise. Where does this categorization come from? Architecture. Taking a project-first approach is backwards. Projects should not define the categories and the architecture, the categories and desired architecture should define the projects.

So, you can see that this simple concept really does represent a fundamental shift in the way of thinking that needs to occur, and it’s one that’s not going to happen overnight. If you’re a CIO, it’s time to get this message out and start defining the steps you need to take to move your organization from a provider to an advisor.

Tibbr and Information in the Enterprise

Back in March of this year, I asked “Is Twitter the cloud bus?” While we haven’t quite gone there yet, Tibco has run with the idea of Twitter as an enterprise messaging bus and announced Tibbr. This is a positive step toward the enterprise figuring out how to leverage social computing technologies in the enterprise. While I think Tibco is on the right track with this, my pragmatist nature also sees that there’s a long way to go before these technologies achieve mainstream adoption.

The biggest challenge is creating the robust information pool. Today, the biggest complaint of newcomers to Twitter is finding information of value. It’s like walking into the largest social gathering you’ve ever seen and not knowing anyone. You can walk around and see if you overhear someone discussing something interesting, but that can be a daunting task. Luckily, however, there are millions of topics being discussed at any given time, so with the help of a search engine or some trusted parties, you can easily begin to build the network. In the enterprise, it’s not quite so easy.

When looking at information sharing, here are two key questions to consider:

  • Are new people receiving information that they would not otherwise have seen, and are they contributing back to the conversation?
  • Are the conversation groups the same, but the information content improved in either its relevance, timeliness, quality, preservation, or robustness?

If the answer to both of those is “no”, then all you’ve done is create a new channel for an existing audience containing information that was already being shared between them. Your goals must be to enable one or more of the following:

  • Getting existing information to/from new parties
  • Getting new information to/from existing parties
  • Delivering more robust/higher quality information to/from existing parties
  • Delivering information in a more timely/appropriate manner to existing parties
  • Making information more accessible (e.g. search friendly)

The challenge in achieving these goals via social networking tools begins with information sources. If you are an organization with 10,000 employees, only a small percentage of those employees will be early adopters. Strictly for illustrative purposes, let’s use IT department size as a reasonable guess to the number of early adopters. In reality, a lot of people IT will jump on it, as will a smaller percentage of employees outside of IT. A large IT department for a 10,000 person company would be 5%, so we’re looking at 500 people participating on the social network. Can you see the challenge? Are these 500 people merely going to extend the conversations they’re having with the same old people, or is the content going to meet the above goals?

Now comes along Tibbr, but does the inclusion of applications as sources of information improve anything? If anything, the way we’ve approached application architecture is even worse than dealing with people! Applications typically only share information when explicitly required by some other application. How many applications in your enterprise routinely post general events, without concern for who may be listening for them? Putting Tibbr or any other message bus in place is only going to be as valuable as the information that’s placed on the bus and most applications have been designed to keep information within its boundaries unless required.

So, to be successful, there’s really one key thing that has to happen:

Both people and applications must move from a “share when asked” mentality to a “share by default” mentality.

When I began this blog, I wasn’t directing the conversation at anyone in particular. Rather, I made the information available to anyone who may find it valuable. That’s the mentality we need in our organizations and the architecture we need in our applications. Events and messages can direct people to the appropriate gateway, with either direct access to the information, or instructions on how to obtain it if security is a concern. Today, all of that information is obscured at a minimum, and more likely locked down. Change your thinking and your architecture, and the stage is set for getting value from tools like Tibbr.

Book Review: Cloud Computing and SOA Convergence in Your Enterprise by David Linthicum

Full disclosure: I was provided a review copy of this book by the publisher free of charge. From the back cover: “Cloud Computing as SOA Convergence in Your Enterprise offers a clear-eyed assessment of the challenges associated with this new world–and offers a step-by-step program for getting there with maximum return on investment and minimum risk.”

My review in a nutshell: This is a very well-written, easy-to-read book, targeted at IT managers, that provides a robust overview of Cloud Computing and its relationship to SOA, and the core basics of a game plan for leveraging it.

This book was an extremely easy read, which is to be expected of any book from Dave, based upon the easy to read style of his InfoWorld blog. He provides a taxonomy of cloud offerings, extending the typical three categories (Software-as-a-Service, Platform-as-a-Service, and Infrastructure-as-a-Service) to eleven. While some may think eleven is too many, the fact remains that a taxonomy is necessary as a core starting point, and Dave provides solid definitions for each category that an organization can choose to use. He goes on to provide a financial model to consider for making your cloud decisions, but correctly states that cost is only one factor in the decision making process. He provides the other dimensions that should be associated with your decision making process in equal detail. In chapters 5 through 10, he walks through steps associated with moving services, data, processes, governance, and testing into a cloud environment. Dave’s steps for these chapters are very straightforward. That being said, Dave does not sugarcoat the fact that these steps are not always easy to do, and your success (or lack of it) is highly dependent on how large of a domain you choose to attack.

For someone who has researched SOA and Cloud Computing in detail, this book may not provide a lot of new information, but what it does provide, is a straightforward process for organizing your effort and making progress. Often times, that can be the biggest challenge. For this reason, I do think the book is more geared toward the management side of IT, and less so toward the technical side (architects and developers), but as an architect, I did find the taxonomies presented valuable. The only area for improvement that I saw would have been a stronger emphasis on the role the service model must play in the selection process, and stronger emphasis on having service managers inside your IT organization. Dave discussed both of these topics, however, to make stronger ties between SOA and Cloud Computing (or even ITIL and Cloud Computing), these points could have been emphasized more strongly. Choosing the right cloud provider requires that you have solid requirements on what you need, which comes from your service model. Ensuring that your requirements continue to be met and don’t get transformed into what the service provider would prefer to offer requires solid service management on your side.

Any cloud computing initiative will require that everyone involved have a base level of understanding of the goals to be achieved and the process for doing it. This book can help your staff gain that base understanding.

Architecture Governance

Mike Walker has had a series of good posts recently on the subject of architecture review boards, but this one in particular, which focuses on governance, caught my attention. In my SOA governance book, I made the obligatory analogies to municipal/federal government in the first chapter, but I didn’t go so far as to compare it directly to the three branches of government here in the United States. I’ve thought about doing this, but never quite put it all together. Thankfully, Mike did. In his post, the following parallels are drawn:

  • An architecture review board (ARB) is analogous to the Judicial arm of the US Government. It reviews individual projects and has the power to decline progress of those projects. Mike also adds that it performs enterprise wide decision making, but more on that later.
  • An architecture guidance team (AGT) is analogous to the Legislative arm of the US Government. It sets principles and policies, creates standards, and oversees the technology lifecycle.
  • Architecture Engagement Services (which typically includes the EA team) is analogous to the Executive arm of the US Government. It defines strategy, designs the enterprise architectures, and performs IT portfolio management.

I had some good conversations with my colleagues on this post and wanted to raise up some of the topics here. First, let’s come back to the role of the ARB/judicial branch in decision making. The ARB doesn’t make architecture decisions, the ARB verifies whether or not the decisions made by the project team follow the law. The only decision the ARB should make is whether the project can proceed forward or not. Mike goes on to state that there should be a clear separation of duties, and that senior IT decision makers should be in the ARB, while the AGT should be filled with SME’s. In my experience, this is normally not the case. I’ve typically seen approaches where the membership of these two groups overlaps significantly. I think this is directly attributable, however, to the effectiveness of the AGT.

One of my pet peeves is when the expectations of a review are not clear. Expectations are unclear when the policies and standards either don’t exist, aren’t widely communicated, or aren’t sufficient. When we get into these grey areas, a group solely focused on enforcement of standards will struggle. In other words, if there’s no laws that apply, one of two things will happen. One, you’ll get an “activist judge” who will interpret the law according to their own opinions, effectively setting policy rather than enforcing the law as written. Second, you’ll go by the letter of the law and deem the space to be uncovered, and as a result, the project can do whatever it wants. Most organizations don’t want the latter, so to hedge their bets, they put the policy makers as judges so they can provide new policy on the fly. That doesn’t bode well, in my opinion, because it now creates an environment where project reviews are likely to be painful, as the things called out will be based on the opinions of the review board, which are undocumented and cannot be anticipated, rather than on the standards of the company, which are documented and can be anticipated by a project team.

The second area I wanted to call out was the separation of the legislative effort from the executive effort. I really liked this separation, and just like an ineffective AGT impacts the ability of the ARB to do its job, an ineffective executive branch will make the AGT ineffective. Mike states that the AGT should consist of technology SMEs, and I agree with that, to a point. The inherent risk is that technology experts (and I’ve been in that role and probably guilty of this at times) can get caught up in advancing their technology rather than executing the strategy. If the AGT isn’t first focused on creating policies and standards that realize the strategy, they will be at risk of hitting gridlock in areas where multiple solutions exist. Take the current health care debate. The strategy has been made clear by the executive branch. If the legislative branch focuses too much on individual party ideology rather than on the strategy of establishing universal health care, gridlock will ensue (except that in this case, one party has a super-majority). The same holds true in the enterprise. Technology advocates can wind up in endless debate on their preferred platforms and completely lose sight of the strategy. At the same time, if the strategy is vague, then there’s no way the legislative branch can do its job. The AGT could set out to establish enterprise standards, but if the executive team isn’t clear on where enterprise standards should exist and where they should not, the wrong areas can be targeted, making adherence to those standards a challenge.

In short, I really like the three-branch model of governance proposed by Mike. It’s a triangle, the strongest structure. It’s strongest when each leg is the same length, working in balance. Make one of those legs smaller, and the other two must lengthen to pick up the slack. If your governance efforts are effective in all three areas, you will have a very strong architecture. If your efforts are ineffective in just one of these areas, you may have your work cut out for you.

Facebook for the Enterprise

In this blog on IT Business Edge, Dennis Byron discussed Facebook as an enterprise software company. His thoughts were based on a keynote address from Chris Hughes, co-founder of Facebook, given at the 2009 annual National Association for Multi-Ethnicity in Communications conference. Dennis stated that Chris indicated that Facebook is much more business friendly than what may have been the perception just two or three years ago. After reading it, it was my opinion that the position being advocated was the use of Facebook, as is, for corporate purposes. That already occurs today, but primarily as another B2C channel, used by marketing types. There are some pioneers out there doing more, but of the ones I’ve seen, it’s all about the customer/potential customer community.

In my opinion, viewing Facebook solely as a marketing/customer support channel is seriously limiting its use to an enterprise. The conversation should begin with an analysis of the communities that can be supported. Guess what? There’s a looming community with a very complicated social structure that exists within the walls of the company. Why can’t tools that are designed for enhancing communication and interaction between the social structures of society be applied within the walls of the enterprise?

Personally, I see this as having potential for a revolutionary change, rather than evolutionary change, in the way inter-company communication goes on and there’s a simple analogy to the world of SOA. Today, and even before the days of email, groupware, collaboration portals, etc., the primary model is still directed conversation. You’re either in the loop, or you’re not. To compare this to SOA, it’s a world where our focus is still on application A calling application B. What’s missing is support for undirected conversation. Combine SOA with EDA, and you have a much more powerful environment. The actions taken by application A and application B are events, and those events may be valuable to other applications. If those other applications have no visibility into those events, that value is left on the table. The same goes for our social interactions. If that information is kept private, there is value left on the table. You may counter, “It’s all out there in my SharePoint site,” but that doesn’t constitute an event-based system. While the information is there, it’s not conducive to searching, filtering, reading, etc. This is where an environment like Facebook has the potential to add much more than an email/IM/portal-based environment that is the norm today. The key is the news feed. It consists of messages from people (friends), but also from applications, coupled with more of the traditional collaboration tools of messaging, chat, file sharing, etc. While the Facebook news feed may not be quite as flexible as Twitter feeds, it’s clear that it’s headed in that direction. The key to success, however, is getting those events published. If applications don’t publish events, it’s hard to achieve the full potential of SOA and BPM. Add employees to that sentence, and it’s hard to achieve the full potential of the organization.

Unfortunately, asking a corporate enterprise to simply start using the public Facebook for these purposes is asking for too large of a leap. While I do think we will get to the point where the technology must allow the corporate communications to extend to parties outside the company, today, it’s still largely a private conversation. Requiring companies to fit their needs into the current consumer-driven, public environments is a big leap for old established companies. The right first step is an environment that packages up all the features of Facebook that are appropriate for a corporate environment and make that available initially as it’s own private world, but with a clear path to integration with the broader, public Facebook. This doesn’t mean that they’re installing it in their own data center, although that could be an option, it just means that it’s a walled garden for that company. It’s like the difference between Yammer and Twitter.

I’m looking forward to seeing more stories of companies leveraging social networking platforms inside their walls and then taking the next step of extending that to external communities as appropriate. I hope that we’ll see some case studies out of some large, established enterprises and not see adoption limited to the world of the new startups that begin with a culture built around these tools.

Oracle OpenWorld: SOA-Enabled BPM Adoption, Reference Architecture and Methodology Aspects

Full disclosure: I’m attending Oracle OpenWorld courtesy of Oracle.

The speakers for this session were Manas Deb, Sr. Director, SOA/BPM/Governance Product Management from Oracle and Mark Wilkins, Enterprise Architect, EAP, from Oracle.

They framed up the session as a discussion based on best practices from their EA practice, focused on companies who have a goal to adopt to BPM, built on a foundation of services. They began with a quick recap on what they feel SOA and BPM are, with SOA being focused on encapsulation and loose coupling, and BPM being focused on improved efficiency. I’m not going to debate those definitions here, just repeated them to understand the context of the presentation.

They, like many others, extended the three tier model to insert processes between the presentation tier and the service tier. The one thing that they did do was to not claim the process layer was a new tier, rather, they presented it as an extension of the services tier. Obviously, the one risk with this is it immediately puts BPM into a technology context, rather than a business context. This isn’t a problem, but it shouldn’t be the sole focus of your BPM and SOA conversations. It may be the cornerstone for conversations with IT developers, engineers, and solution architects, but certainly not for analysts, business architects, and other non-IT staff.

The first slide on methodology is emphasizing what they are calling scopes. The examples shown include enterprise (cross-project) scope, project scope, and operations scope. At the enterprise scope, the interest is assessment, strategy, and planning. It performs value-benefits analysis, forms CoEs, establishes roadmaps and maturity models, plans the portfolio, establishes governance, etc. The project scope is execution and delivery focused, the operations scope is focused on measurements, scorecards, and keeping things running. It’s important to keep these scopes, or viewpoints, in mind and ensure that they all work together.

Mark went on to blow through a whole bunch of slides way too quickly. This should have been a 60 minute presentation. It appeared that there was some good content in there, including Oracle’s approach to the use of BPM and SOA conceptual reference architectures and how they eventually drive down to the physical view of the underlying infrastructure. He went on to show examples of the conceptual architectures for BPM and SOA, some information on a maturity model, a governance framework, and a few slides that tried to fit it all together. Once I’m able to download the slides, I’ll try to remember to come back and edit this post with the details. It’s unfortunate that a presentation that appeared to have very good content with appeal to architects got crammed into half the time frame of the other sessions.

Oracle OpenWorld: EA, BPM, and SOA

Full disclosure: I am attending Oracle OpenWorld courtesy of Oracle.

The speaker is Dirk Stähler from Opitz Consulting And he is talking about how to bridge the information gap using Oracle BPA Suite and an integrated model.

He started by presenting the EA, BPM, and SOA problem which includes no unified methodology, unclear semantics, and no differentiation between EA, BPM, and SOA aspects.

He presented the three domains in a Venn diagram and called out the overlap in artifacts from each, including org structure, infrastructure, business processes, IT systems, and business objects. This overlap forms the foundation for the metamodel which can be captured in Oracle’s BPA suite.

In discussing this, he presented a pyramid, where EA is at the top (providing a conceptual blueprint of the org), underneath that is business process management (as a business design tool), then comes technical business process management (for IT specifications), and finally is information technology (supporting development). SOA spans one leg of the pyramid, impacting all four layers.

In discussing the artifacts, he defined domains for process architecture, application architecture, infrastructure architecture, data architecture, organziation architecture, and service architecture. All of the artifacts can be captured in BPA suite. In aligning this to EA, BPM, and SOA, he feels that EA covers app and infrastructure architecture, BPM covers organization, process, and data, and SOA covers service and some of data.

After this, he switched to a demo of the BPA suite, showing how to navigate the metamodel, associate different diagram types with different domains, etc. As someone with no experience with BPA suite or any other EA tooling, this was a good overview of how BPA suite could be used to manage the various models associated with an EA practice. The metamodel description covered how to separate these things within BPA suite, however the talk did not get into any issues or concerns with having two or even three different audiences using one centralized tool and repository, making sure they leverage each other’s work where appropriate.

For more information, they have published a book on their methodology, however it is currently only available in german.

Oracle OpenWorld: An Intro to the Oracle Enterprise Architecture Framework

Full disclosure: I’m attending Oracle OpenWorld courtesy of Oracle.

Speakers:

  • Mark Salser, Senior VP, Enterprise Solutions Group
  • Mark Dickson, Systems Architect, Cochlear Americas
  • Edward Screven, Chief Corporate Architect, Oracle
  • Paul Cross, Group Vice President: Sales Consulting, Oracle

Quotes from Mark’s intro: “Why has Enterprise Architecture become more important? The issues are moving more toward enterprise level issues … Think about enterprise architecture as a strategy for your business. It is a strategy for how you bring business and IT together and requires a holistic view of the business. … Ultimately you want to create a collection of prescriptive guidance … that takes you down this path of operational excellence.” Five key points on slide: rationalize, standardize, consolidate, optimize, and innovate. “Enterprise Architecture is about establishing the foundation for an optimized IT core.” On the slide, it emphasizes that this foundation is based on architectural principles, best practices and reference architectures, industry and corporate standards, technology trends, and a rationalized IT portfolio, with a business model, strategy, and objectives at the center.

There’s a slide up now that shows a simple view of what they consider to be the core. It has the standard three tier view of user interaction at the top, application services in the middle, and a technology foundation at the bottom. In between the user interaction and the application services layers is a composite business process layer.

After a slight detour for an interview with Edward Screven, Oracle’s Chief Corporate Architecture, they are getting back to a framework (hopefully). They presented some typical guiding principles for EA, and then split EA up into three areas: people, process & framework (architecture development process, EA framework), and portfolio (Oracle Enterprise Architecture Repository, Services and Products).

The Oracle Architecture Development Process looks very TOGAF like, the Oracle Enterprise Architecture Framework consists of business architecture, application architecture, information architecture, and technology architecture, with people, processes, and tools on one vertical and EA governance on the other vertical. Underneath it all is an EA repository.

The EA repository consists of best practice reference architectures and patterns from their own practices and customer practices. They are encouraging us to use this as a jumpstart. They’re showing a number of models from the repository (very quickly, unfortunately), but there’s some very good information there. Unfortunately, I asked if those models are publicly available and they are not. An engagement with EA Professional Services is not required, as there are architects from the team that participate on Oracle Mix, and they can make information from the repository available in direct response to the public discussion. Hopefully, Oracle will see this post and establish a process to publish some of these models via ITN on a regular basis rather than keeping them hidden until requested. While I understand the need to keep a certain amount of intellectual property private in support of a consulting practice, there is still some basic reference architecture information that should be available simply for being an Oracle customer that we can pull ourselves in support of our own EA efforts.

Architecture is about appropriate context

I reviewed an architecture capability model from a colleague recently and one of my responses was that I didn’t like the categorization that was used for the capabilities. While I had no issue with the capabilities themselves, the way that it was organized didn’t make sense to me. I probably spent more time trying to figure out why those categories existed rather than focusing on the capabilities themselves, which were the more important factor.

Enterprise architecture is all about context. EA, by itself, doesn’t deliver technology solutions. A traditional architect delivers a model of a structure, someone else goes off and builds that structure. The architecture provides the context that constrains the decisions made by the builders. Provide poor context, and you increase the chances you’ll wind up with a poor building. My wife has been watching Design Star on HGTV, and it’s very interesting watching the home owners interact with the future designers. A key thing these designers are being judged on is their ability to understand the needs of the home owners. This includes not just what the home owners say (and don’t say), but also the entire space around them. The designer could come up with a great design when evaluated in a vacuum, but if it’s out of context of everything around it and the wants of the home owner, it is a failure.

The same holds true in the world of IT. Provide poor context, and you increase the risk that the developers will build something that just doesn’t work well with everything around it. As Enterprise Architects, it is our job to provide appropriate context for the enterprise concerns. Project sponsors are provide context of their functional needs, it all must be balanced together.

Getting back to my opening statement, as technologists, often times we wind up focusing on providing a context, rather than the right context. It is easy to get caught up in the categories rather than the things being categorized and the purpose for which they are being categorized. I strongly believe that there are always multiple ways of categorizing something, and whether it’s appropriate or not is based on the purpose of the categorization. This is consistent with the multiple viewpoints approach emphasized with TOGAF. Don’t get caught up in coming up with one good categorization for one purpose and then trying to cram that same categorization into everything else you do, because it probably won’t fit. The context must be appropriate, and it’s the job of enterprise architecture to deliver it.

The Future of EA

A Gartner press release resulted in some very good posts in the blogosphere related to the future of enterprise architecture. Gartner coined the term ’emergent architecture’ and encouraged companies to adopt it. For the record, I’ve decided that I really don’t like that term, and I don’t think Gartner did a very good job of defining it. They provided a list of seven differentiators from “the traditional approach to EA” but, as Mike Rollings of Burton Group pointed out in his post, most of these things are items that many practicing enterprise architects already did and knew. Do we really need a term for what many of us are already doing?

The post that I really liked came from Dion Hinchliffe at ZDNet. The reason for this is the image that he used in the post, shown here:

While I still don’t like the use of the term emergent architecture and “non-deterministic outcomes”, the picture tries to draw a picture of the forces the come into play in producing solutions.

So what is the role of EA in the future? First, the thing that doesn’t change is the role of EA in providing context. This context is an influencer on the activities that occur in the enterprise. Dion’s drawing attempts to touch on this, but goes at the scope of influence in terms of who can be influenced, rather than the information used to influence. It’s the role of the enterprise architect to bring additional context from outside of the normal scope of the effort to the solution discussion. Influence is not about centralized decision making, so as Mike Rollings called out, most EA’s have never been a centralized decision maker for all things architecture and never will be. We’re simply another party providing influence. Sometimes we have stronger methods, sometimes someone else does. In my book, SOA Governance, I emphasized policy creation first, then policy communication. If the policies are known, any decision maker can apply those policies consistently.

What Dion’s diagram doesn’t capture, is the changing way in which solutions get done. He still has the “projects” box up there. There are many of us that feel this project-based culture is part of the problem. If we take a more product-based or even service-based view of our solutions, those solutions will need to be nurtured and evolve over time, rather than stood up, ignored, and then uprooted with significant effort. This notion, as others have called out, including Neil Macehiter and Neil Ward-Dutton in their book The Technology Garden and practicing enterprise architect James McGovern in his blog, is that of gardening. Do you simply let anything emerge in your garden? No. You plant specific things, remove the weeds, remove weak plants, change some things from year to year, etc. If you don’t plan the garden properly, weeds can choke the life out of other plants, or there can be conflicts within the garden itself, with one type of plant consuming higher amounts of resources, causing others to wither and die.

Coming back to the role of EA as influencer though, the thing we must realize is that the dynamics around us are changing, and as a result, it may change who and how we influence. More and more things are bought rather than built. The level of consumer technology has changed the bar in terms of what individuals can do and expect. If we don’t change our ways along with it, our ability to influence will be diminished. This doesn’t mean things are now emergent. There have always been things that have been emergent, and a healthy company always has some efforts that fall into the category of throw it against the wall and see if it sticks. What’s changed is the pace at which we can do it. We need to incorporate this into the way we execute. I believe the trend toward business architecture is a clear sign of EA trying to do this. We must remember, however, that the artifacts and techniques used to provide context to developers and engineers may not work with the business. We need to speak the business language, not try to get them to understand ours.

SOA and Reuse

In a two-part podcast series, Dave Berry from Oracle’s Fusion Middleware team and Mike van Alst, a consultant with IT-eye, discussed some remarks I made in an earlier OTN Arch2Arch podcast regarding SOA and reuse. Specifically, I tried to de-emphasize the reuse aspect of SOA. Many reuse programs that I’ve seen or read about have two key elements:

  1. Building things in a reusable manner
  2. Making those things visible

While noble goals, these approaches are at significant risk of producing the intended results. The first item has a fundamental problem in that it is all but impossible to define exact what “building in a reusable manner” is. We can use open, interoperable standards rather than closed, proprietary ones, but is this the key barrier to reuse? There’s probably some low hanging fruit that this will capture, but there’s so much more to reuse than this. From a technical standpoint, one must also consider the structures of the information being exchanged and the varying granularity of the information being exchanged, among other things.

On the second item, visibility is important, there’s no doubt about it. But visibility without context will not be successful. It’s a matter of providing the right information at the right time. Too many initiatives that are associated with the collection of IT artifacts, be it reuse, SOA, portfolio management, ITSM, or any of the like, fail because the information is never put into the context of the processes that need that information. How many times have you seen the information collected as part of a fire drill for an immediate need, only to grow stale once that fire drill is completed.

The two things I recommend are service ownership and linkage to key IT processes. If you’ve heard me talk on panel discussions at conferences, you’ll know that my answer to the question, “What’s the one piece of advice you have for companies adopting SOA?” has always been, “Define your service owners.” Someone is given the responsibility for a functional area, providing capabilities to the rest of the organization and accountable for driving out the redundancies that may exist. This is a tricky exercise, because service ownership has a cost associated with it. Expending that cost for a service that is only used by one consumer can lead to waste, so it’s not a silver bullet. It does, however, being the cultural change from a project-driven organization to more of a product-driven/service-driven organization. Without having someone accountable for the elimination of redundancy in a domain and serving the needs of consumers, it won’t happen.

The second piece of advice is the process integration. To avoid creating repositories that see infrequent use after initial population, you have to define the role of that information in the IT processes. If you have a service repository, when do you expect project architects and designers to look into that repository for services that may be appropriate. How about it the strategic planning process? The scoping effort for a project likely begins long before a project architect is assigned? How is the service repository used in those activities? By defining the links with key IT processes and ensuring that those processes are changed to use the repositories involved, with appropriate governance to make sure those changes are occurring, you will make sure that your services are visible, and more importantly, that the right people are looking for them at the right time.

EA Service Management – Reporting

This is another blog on the subject of a service-based view of Enterprise Architecture. Previous posts focused on the actual service definitions (here and here) and a general view on communications, this one focuses on the actual management of those services, specifically on the notion of reporting.

In my experience, as teams try to transition to a service-based view, a key challenge is in moving from an inwardly-focused view to an outwardly-focused view. In other words, shifting to a focus on the customer. An easy way to encourage this shift is to think about your communication to the customer. If you think of examples of great service, it goes beyond the communication associated with service execution. As a simple example, think about your credit card. There are credit cards that simply allow you to make your purchases and then send you a bill. Some cards, however, send you a report every year that gives you information on how you’ve used your credit allowing you to make better financial plans. So, how can we take this same approach to the EA (or any other) service offerings?

The simple part of this is to make a commitment to communication with your customers. At a minimum, think about reporting to your direct customers and their management. In all likelihood, you’ll need to add two additional audiences to this. First, is senior management over EA. Depending on where EA sits in the organization, this could be senior IT leadership or it could be senior enterprise leadership. Second, is the group most people are used to dealing with, and that’s internal management of EA. The more complicated part of this is figuring out what to report and how frequently to report it. I hope to cover this in more detail in a future post, but for now, think about how you can add additional value to the relationship. Rather than simply reporting status of engagements, provide additional value through an analysis of activities, added information from EA research services, or some transparency into the activities occurring within Enterprise Architecture.

Ads

Disclaimer
This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.