Todd Biske: Outside the Box

Archive for the ‘Governance’ Category

My latest article for SearchSOA has just went live. It gives a series of tips for making project governance more efficient. You can read it here.

While I have not yet embarked on writing another book, I have been published in a second book. The publisher of my book on SOA Governance, Packt Publishing, has released their first compendium title called, “Do more with SOA Integration: Best of Packt.” It features content from several of their SOA books and authors, including some from my book on SOA Governance. If you’re looking for a book that covers a more broader perspective on SOA, but has some great content on SOA Governance as a bonus, check it out.

On a related note, I’ve been toying with the idea of authoring another book, this time on Enterprise Architecture. There are certainly EA books on the market, so I’m interested in whether all of you think there are some gaps in the books available. If I did embark on this project, my goal would be similar to my goal on my SOA Governance book: keep it easily consumable, yet practical, pragmatic, and valuable. That’s part of the reason that I chose the management fable style for SOA Governance, as a story is easier to read than a reference manual. If I can find a suitable story around EA, I may choose the same approach. Please send me your thoughts either by commenting on this post, or via email or LinkedIn message. Thanks for your input.

Every organization has one. For some, it can lead directly to a path of enlightenment. Others may use its rigid structure to create an impenetrable fortress of strength. For the unfortunate, it becomes an inescapable labyrinth of hopelessness. Yes, it’s the org chart.

Okay, let’s be fair, it’s actually not the chart that’s the real challenge, it’s the organizational structure. Any organizational structure creates boundaries, and those boundaries create opportunity for divergence, whether in strategy, opinions, processes, or just about anything else. The challenge is figuring out how to structure the organization to diverge where you need divergence, but to be consistent where you want consistency. It’s no surprise that organizational structure is considered by some to be part of the enterprise architecture. Just as we try to organize our technology portfolio in the best manner to achieve the desired business goals, we need to organize our human resources as well. More importantly, just as management may choose to reorganize its human resources as the business goals and operating context changes, the way we organize our technology portfolio needs to change as well.

The organizational structure poses a particular challenge for the practice of architecture, particularly when it comes to solution architecture. I’ve seen at least three different models for organizing the architecture practice. First, is the centralized model where all architects report up to a single Chief Architect or Director of Architecture. There may be some middle management in there, but there is always a solid line leading to the top. As you might guess, this usually leads to a high degree of consistency, but can have challenges in scaling to meet demand, retaining business domain knowledge, and of course, ensuring that the centralized resources actually get used by projects and avoiding “rogue architecture.” The overuse of the term “architect” in job titles these days makes this even more problematic, as senior or lead developers may now have the title of Java/.NET Architect. It may also create delays in decision making, because the solution delivery has one reporting structure, while the solution architecture has a different reporting structure. If there is a disagreement, these two management structures must come together to resolve the difference, or it must be escalated up the chain.

A second model is a separation of the Enterprise Architecture function from the Solution Architecture function. Enterprise Architects have a solid line to the Chief Architect/Director of Architecture, Solution Architects report through a different structure, perhaps having a dotted line back into the EA organization in a matrixed structure. Consistency becomes more of a challenge, because Solution Architects will likely receive more direction from their management structure than from the EA team. It also creates challenges for the EA function, because now the EA team is at risk of being completely disconnected from solution delivery. Even in the centralized model, the bulk of the input into the solution comes from the solution management side of things. Now, that push will be even stronger, with architectural management struggling to maintain a voice. That voice is sometimes mandated through an architectural review board, but if that’s the only time that architectural management has the solution architect’s ear, the effort is likely to struggle with EA being seen as an ivory tower, rather than a necessary contributor to solution success. I’ve seen this model more than either of the others, however.

The third model would be the completely decentralized model. In this case, there is still a practice of architecture in the organization, but it is completely distributed. Solution architects, and perhaps domain architects, are scattered throughout the organization. A virtual team may exist, and there may even be a Chief Architect/Director of Architecture, but the role may largely be one of information sharing and coordination, and not really about architecture management. What’s good is that there’s not much risk of being perceived as an ivory tower, but there is significant risk of poor architectural alignment. If the boundaries of diversification are based upon an assumption that business units do not share customers, what happens if the situation changes and they do? Even ignoring the potential for this situation, decisions on centralization versus a matrixed approach are likely made locally within each business unit.

So what model is right? First, a completely decentralized approach is really only suitable for companies with a completely diversified operating model (see this book if you don’t know what that means). So, it really comes down to centralized versus matrixed, and that will either be applied at the business unit level for a diversified company, or at the enterprise level for other operating models. Both centralized and matrixed can work, but there is a catch. I’ve used the term “architecture management” in this blog. As I wrote this, I kept thinking about parallels to project management and a PMO. I’ve seen centralized PMOs where all project managers report into a single organizational group, and I’ve seen decentralized PMOs where individual project managers report into lines of business while a core group of resources that look at things from a portfolio perspective report into a Director of Product Management. The catch is consistency. If each project manager did things their own way, it is going to be extremely difficult for anyone to manage things at a portfolio level. Without establishing some minimum level of consistency that produces the necessary metrics and information at the right times for portfolio level management to happen, you’re sunk. Fortunately, for project management, the need for this is a well accepted practice. No one wants to wait to find out that a project is $100M over budget until after it happens. If you have that consistency, you can make either model work.

In the case of architecture management, things are still maturing. The problem is that we are at risk of focusing solely on consistency, without properly understanding the outcome that consistency is supposed to create. While finding out that you’re $100M over budget after it’s been spent is well understood as a bad thing, is finding out that someone has built a component that already existed elsewhere in the company a bad thing? Not necessarily. Those decisions need to be made in the context of both the project’s goals and the enterprise’s goals to make that distinction. Pursuing enterprise consistency when there are only project goals involved in decision making puts you at risk of being perceived as an ivory tower. At the same time, it may be necessary to pursue some base level of consistency prior to establishing that enterprise context, otherwise the context may be perceived as irrelevant. This can happen when the practice of solution architecture really isn’t being practiced at all.

My final advice is this: a centralized path will definitely lead to the most consistency, but you have to be rock solid in your justification of the need for an enterprise viewpoint, because that centralized model creates management overhead, risk of resource availability, and the potential for conflicting direction. A decentralized model is at less risk of having resource availability issues, but makes consistency more difficult and is more prone to sacrificing enterprise direction for project delivery. Ultimately, it will come down to whether your organization has been successful with matrix management approaches or not. If it has, you should be able to make a decentralized approach work. If you’ve never been successful with matrix management, then a centralized approach will likely be necessary. Finally, if you go with a decentralized approach, but have very inconsistent architecture practices, I strongly recommend that you establish an architecture mentoring/facilitator practice. In this, members of the centralized EA team facilitate one or two day architectural workshops. This can ensure that things are done in a consistent manner, the voice of the enterprise is brought into the solution architecture process, but the risks associated with a completely centralized model are mitigated.

According to ZDNet’s Joe McKendrick’s coverage of the recent Gartner Application Architecture, Development, and Integration summit, SOA governance and siloed thinking is top of mind.

If this really is the case, how do we make our governance efforts more effective? The more I think about this, the more I come back to a recent post of mine from earlier this year: “Want Successful Enterprise Architecture? Define ‘Enterprise’ First.” I’m convinced that this is a critical step for any effort that tries to go beyond a project-level scope, SOA initiatives included. If you don’t provide a structure that says what things will be implemented and managed at an enterprise level, versus a domain level or project/team level, anything with the term “enterprise” will be a struggle.

Too often, the approach to governance is concerned with establishing oversight, not establishing outcomes that are rooted in an agreed upon definition of what will be managed at an enterprise level, a domain level, and at the project level. Does it really help to set a standard that a particular coding library must be used when there is no central team that manages the library, no centralized support team, and no stated strategy for developer portability across projects? No, it just gets people up in arms and accusations of EA or the governance team being an ivory tower that sets arbitrary standards.

In my book, I defined governance as the combination of people, policies, and processes that are put in place to ensure the organization achieves one or more desired behaviors and outcomes. It’s not there to simply have a check mark to that says, “I went through a review.” In the absence of clear desired behaviors and outcomes, that’s what you will have. There is no reason to have an enterprise architecture team review a project if there are no things that are managed (or desired to be managed) at an enterprise level. You need to have some idea of what those things are up front, along with a mechanism for quickly making decisions on new candidates for enterprise items. The project team must know that this analysis will be done, and that it is a necessary part of achieving the company’s strategic goals, which they should be well aware of. Lack of communication of these goals can be just as detrimental and is often a symptom of lack of agreement on enterprise goals or inadequately specified goals: “Sure, we need to cut our IT costs by sharing more systems. I’m all for it as long as they’re not mine.” Someone needs to define exactly what the target areas are.

To be successful, we must define the desired outcome first. We must clearly establish the list of things that must be managed at an enterprise level, a divisional level, or left to the discretion of individual projects/teams. In fact, it’s even more fundamental than this. We can’t even know what success is without doing this step. There were no shortage of companies in the past that stated they were adopting SOA, my question to them would be, “How do you know when you’ve been successful?” Simply having a bunch of services doesn’t mean you’ve adopted SOA, it has to be the right services. Too often, enterprise architecture teams are positioned for failure because this fundamental step has not happened. Before you task your enterprise architecture team with reviewing all projects, make sure you’ve defined what enterprise is. If you haven’t, task your enterprise architecture team with doing the analysis of what’s out there and coming up with some recommendations. Then, your governance program will actually have a desired outcome to use in their reviews.

There was a great discussion on Twitter today regarding influence, mandates, and leadership. My interest started with a tweet from Chris Venable, directed at Burton Group/Gartner EA analyst, Mike Rollings:

If EA is so important, why must it do everything through influence? No one ever says that to the CIO…

I thought this was a great question, and after retweeting it, a debate ensued around influence, mandates, and leadership among myself, Mike, Philip Allega of Gartner, Chris Lockhart, and others. In a nutshell, the question is this: Is it possible to be an effective leader without mandates?

My gut answer to this is yes, and I even feel that issuing mandates puts you at risk of being ineffective. As I dug into this, however, I realized that it’s not about the term mandate, it’s about the approach you take to providing leadership. Why is that the case? Look at the definitions for mandate, direction, and guidance, courtesy of thefreedictionary.com.

Mandate: An authoritative command or instruction
Direction: An authoritative indication; an order or command
Guidance: Leadership, instruction, or direction

I don’t see a big difference, do you? Yet, I’m sure we’d all agree that those terms are perceived very differently. Would you rather work for a manager that gave you direction or issued you a mandate? According to the dictionary, it’s really one and the same. Now look at influence:

Influence: A power affecting a person, thing, or course of events, especially one that operates without any direct or apparent effort.

The definition for influence actually mentions the word “power” which could be perceived as a negative, but more importantly, it goes on to state that we use the term more frequently when the power is imperceptible. This is where the difference lies. If mandate and direction mean the same thing, the real difference is when the leader can give that direction and influence the outcomes of the company without pushing so hard that it is perceived as something out of the ordinary at the time it happens.

An arbitrary mandate is like a shove in the back. It will be noticed, and it will be perceived in a negative manner. A justified mandate can be equally jarring, but can be acceptable in the short term. “I shoved you to the side so you wouldn’t walk into the huge pit of snakes that was in front of you because you were looking elsewhere.” The problem with both of these is that they’re “in the nick of time” decisions, and have to be jarring because there’s no other choice. The natural question then, is how did we get here in the first place?

This is where true leadership comes into play. Leadership is about setting people up to be successful from the beginning. That doesn’t mean that course corrections might be needed, but you set expectations early. How many of you have had an architecture review, or even worse, a performance review, where you were criticized for something you didn’t even know was expected? That’s bad leadership. Set the expectations and give people a chance to be successful. In setting the expectations, it must first be about the desired effect (note that nearly all the definitions for influence include either the word affect or effect) and not about the means. If it’s solely about the means, it becomes an arbitrary mandate. For example, “The desired effect is that our IT operational costs go down by 10%. We’re going to do that by consolidating redundant systems for X, Y, and Z.” rather than simply saying, “Everyone’s going to have to use system X from now on.” By not disclosing the desired effect, people will resist the change. By leading with the desired effect, you can also create an opportunity for people to come forward with alternatives. Where the effect is hidden, decisions become arbitrary or personality-driven, rather than outcome driven (see this post).

In a nutshell, set the desired outcome, establish a direction to achieve it, make course corrections as needed with an imperceptible gentle nudge so that it won’t be perceived as a mandate. That’s an example of influence, and that’s an example of leadership.

A key to any Enterprise Architecture program is solution architecture. Solution architecture is where work gets done. If your EA team is disconnected from the solution architecture effort, you’ll probably hear the term “ivory tower” a lot. Unfortunately, it’s far more common than you may think.

Looking the typical project, the first question is where do the solution architects report? Since many times they have grown out of senior development roles, odds are they don’t report into the enterprise architecture organization. On top of that, the key authority figure (decision-maker) within the project structure is typically not an Enterprise Architect, and it’s not even the solution architect’s manager. It’s the project manager and the project sponsor. This leaves a whole bunch of people that need to be influenced. They are:

• The Solution Architect
• The Solution Architect’s Manager
• The Solution Sponsor
• The Project Manager

The Solution Architect. The solution architect is going to get pulled in different ways. I believe that it is the job of Enterprise Architecture to make the solution architect’s life easier, rather than more difficult. If you’re just another voice pulling them in a different direction, it’s not a good situation. Think of yourself as a mentor to the solution architect, and provide them with the tools they need to do their job. Those tools are excellent reference material in the form of standards, guidelines, and patterns, pointers to the right people to talk to, a sounding board for options, and another set of eyes for reviewing work. On top of that, you should consider whether or not solution architects should report into the EA organization, or at least have dotted line reporting structures into EA. Which leads to…

The Solution Architect’s Manager. Assuming solution architects don’t report into EA, someone else is writing their performance review, and odds are, they’re getting judged not on the quality of their architecture but on their ability to deliver. They should be judged on both, and it’s up to the Enterprise Architecture team to work with the solution architect’s manager to ensure their performance objective include architectural objectives. If you don’t, architecture is likely to lose when push comes to shove. Also, keep in mind that you need to have regular conversations with the managers of the solution architects. Odds are they have regular conversations with their business stakeholders, who in turn influence the work that gets done. EA needs to have similar influence.

The Solution Sponsor. This is a challenging one, but very important. It’s challenging because in many organizations, IT relationships with the business are considered protected turf, and people can get really bent out of shape if you have these conversations without them there. I think we need to stop protecting these conversations and instead start encouraging them. If it can help the company deliver better solutions, then get the right people talking to each other, period. What’s really important with the sponsor is to start talking about the architecture of the effort before the funding proposal is made. If you can bring the solution architect with you, even better, because that will build rapport. Make the sponsor aware of the needs of the enterprise, work to get their support, and then when you need to make decisions within the project, the person at the top of the decision making chain should have awareness of not just the financial and schedule needs, but also the enterprise architecture needs.

The Project Manager. Finally, it’s the project manager. If you’ve properly influenced the sponsor and the solution architect, this one shouldn’t be a problem, but we shouldn’t ignore the project manager. It is their job to make sure the right things get delivered. The solution architect should be their partner in the effort, helping them to know when things are going off track from a technical perspective. There are delivery requirements, functional requirements, and architectural requirements, and the PM has to make sure all three are addressed. It is better to discuss the relative priority of each of those up front, rather than deal with the contention in the middle of the project. Will you allow the schedule to slip to maintain the right architecture? Will you sacrifice functionality for the right architecture? Talk about this before it becomes an issue. Also, if you have a formal review process, make sure the PM knows what is needed and what questions are going to be asked. They want the review to go smoothly, so you have to give them the tools they need to know when they’re ready to be reviewed and to pass without any issues.

Hopefully you’ve found this focus on solution architecture useful. As topics come up under this theme of architecture by influence, I’ll have additional posts. If there are specific questions or challenges you have, feel free to send me an email or post it via a comment.

A recent conversation with a colleague delved into the complicated world of new technology decisions. At every organization I’ve been at, this has been a source of contention between four major groups: Enterprise Architects, Domain Architects, Development Teams, and Engineering Teams. I specifically listed Enterprise and Domain Architects separately, because I’ve seen contention between those two groups. It’s easy to come up with scenarios where each one of these teams should be involved, but it’s most problematic when one team tries to “own” the process.

Why does this struggle for ownership occur? Let’s start with a development team. First and foremost, they spend nearly all of their time on projects, which is where things get delivered. They are typically the ones closest to the immediate business need as represented by the project requirements, so they have fewer challenges getting justification or funding. They claim they need the new technology to deliver to the business, so they have a vested stake and want control over the decision.

An engineering team is also involved with projects, but has a challenge of remaining relevant when the project ends. The technology typically gets handed off to an operations team, and if the engineering team has built shared infrastructure, rather than one off infrastructure, there may not be much to do until the vendor releases the next version. Given that, it’s likely that the engineering team will expand into the world of technology architecture, but potentially only with the vendors they know, rather than a vendor-neutral architectural approach. This creates a risk of driving technology adoption based on new features rather than on company need, can create conflict with the technology architecture team, if one exists, and with other technology areas when the continued feature creep results in overlap with other domains. Unfortunately, engineering teams don’t have as much visibility into the business need, because that’s all funneled through projects and the development teams, so it sets the stage for tension between the development and engineering areas.

Now let’s throw in architecture. First, there can be conflicts within architecture teams, if there’s a separation and different reporting relationships for enterprise architects and portfolio/domain architects. Second, enterprise and domain architects can frequently be disconnected from both the “need” process of the projects and the technology delivery of the engineering team. Clearly, the right place for these roles to play is at the portfolio management level, where categorization, prioritization, and strategy takes place that results in the needs of individual projects. That doesn’t always happen though, and these roles often wind up having to get involved by mandate, becoming the gatekeeper or bottleneck that everyone tries to avoid.

As many have said, there are typically far more ways to mess something up than there are to do it correctly, and this is certainly one of them. Coming back to the idea of trusted advisor, my theory is that any approach that tries to mandate that technology introduction only come through one path is probably not going to work. Lots of people get great ideas, and guess what, not all of them come out of any particular role, and plenty of them come from outside of IT. (By the way, the same should hold true in reverse, IT can come up with plenty of good business ideas, just as the business can come up with good IT ideas.) The role of the architect is to be the trusted advisor and provide the appropriate context to make things successful. If someone has a great idea about a new technology, don’t stifle them because you didn’t come up with it, advise them on how to make it work based upon the context you have as an enterprise or domain architect, or advise them that it’s not going to be successful based upon that same context. That’s what an advisor does, and providing the appropriate guidance, whether it is what the other person wants to hear or not, is what will create trust. There will always be people that may be out of alignment with the business needs and priorities, if you don’t create alignment (either by adjusting the individuals view or adjusting your needs and priorities), you will be destined for frustration, splintering, and potential lack of success. Create alignment, and create an environment where appropriate ideas can thrive regardless of the source. That’s the role of the trusted advisor, and that’s a big part of what enterprise and domain architects should do.

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.

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.”

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.

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.

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

I’m having to recreate this post thanks to a bug in WordPress for the iPhone which managed to eat a couple posts, so my apologies for it being a bit shorter than hoped, since I had to recall what I was typing live.

In this session, James Kao from Oracle presented five steps to improving SOA governance. The core premise that was emphasized throughout is that the use of metadata is becoming more and more prevalent in the development world, as it is necessary to increase the efficiency of our development efforts. Examples include SCA descriptors and BPEL. We will have a big problem, however, if the operational tools can’t keep up with these advances. This same metadata needs to be leveraged in the run-time world to improve our operational processes. I’ll add to this that while much of the metadata is coming out of the SOA and BPM technology space, this concept should not be limited to just those areas. The concept of having metadata that describes solutions for gains in both the design time world and the run time world is extremely important.

The five steps presented were:

1. Assess. (sorry lost the details on this one)
2. Discover. This is where the metadata created at design time is leveraged to set up appropriate run-time governance.
3. Monitor. The systems must be instrumented appropriately, exposing metrics, in addition to leveraging external monitors to collect information about run-time behavior.
4. Control. The four examples given here were policy management, service management, server/service provisioning, and change management. Clearly, this is the actionable step of the process. Based upon the data, we take action. Sometimes that action is reflected in changes to the infrastructure via provisioning and/or change management, sometimes that action is modifications to the policies that govern the systems.
5. Share. Finally, just as the metadata from design time played a role in the run time world, the metrics collected at run time can play a role in other processes. The information must be shared into systems like Oracle BAM or Oracle ER to provide a feedback loop so that appropriate decisions can be made for future solutions.

I was very impressed with James’ grasp of the space. While this session presented concepts and not a live demonstration, if Oracle Enterprise Manager can make these concepts a reality in a usable manner, this could be a very powerful platform for companies leveraging the red stack. Excellent talk.

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

I’m having to recreate this post thanks to a bug in WordPress for the iPhone which managed to eat a couple posts, so my apologies for it being a bit shorter than hoped, since I had to recall what I was typing live.

In this talk, Vikas Jain gave an overview of Oracle Web Services Manager, and Josh Bregman (I think) gave a demo of integration between Oracle Web Services Manager (OWSM) and Oracle Entitlements Server (OES). For most of his portion, Vikas went over the architecture behind WSM. It hasn’t changed too dramatically since I first saw it back as Confluent years ago, and that’s a good thing, since it had proper separation between policy enforcement and policy management. One thing I didn’t know, which is a good thing, is that the WSM enforcement point is now an embedded agent within WebLogic Server. That is, it comes with WebLogic server, there’s no separate install for it. This is a very important point, because if you need to do end-to-end identity propagation, you’ll need some kind of agent or native support for your identity formats on every node in the call chain. They did mention E2E identity propagation on a slide, but they didn’t go into any depth on it.

From a feature standpoint, OWSM has all of the necessary WS-* features necessary, including WS-Policy, WS-Security, SAML support, and WS-ReliableMessaging to name a few.

One thing I was disappointed with is when they presented a slide on integrations with the rest of the fusion middleware, Oracle Service Bus was not shown. SOA and WebLogic was a line item, and since OSB runs on WebLogic, it could be inferred that there’s a relationship, but what I wanted to know about was the significant functionality overlap between OSB and OWSM. I did get to ask about this, and the first answer was that they felt there wasn’t a lot of overlap, and frankly, I don’t agree with that in the slightest. On the plus side, however, they did say that in a future release of Oracle Service Bus, the security features of OSB will be fully provided by the OWSM agent, and not by the underlying WebLogic (non-OWSM) capabilities as is currently done. If this is the case, then they are working to eliminate the functional overlap, however, there’s a long way to go. Oracle Service Bus is a policy enforcement point, just as Oracle Web Service Manager agents are. OWSM can do more than just security, just as OSB can. Hopefully, this will be resolved in the future, and customers will not have to choose between two products from the same vendor to attack the same problem of enforcing service contract policies through a service intermediary.

For those of you attending Oracle OpenWorld, please come to my session on Monday the 12th at 4:00pm in the Golden Gate 3 room of the Hilton Hotel. I will be participating in a panel discussion on SOA Governance best practices. Based on the pre-call sessions I had with the other panelists, it should be a very informative session. While you’re at the conference, stop by the conference bookstore and pick up a copy of my book. Thanks to my publisher for making it available.

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.

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.