Archive for the ‘IT’ Category

Oracle OpenWorld: Five Steps to Better SOA Governance with Oracle Enterprise Manager

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.

Oracle OpenWorld: Using Oracle Web Services Manager to Manage Security

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.

Oracle OpenWorld: Michael Dell Keynote

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

Michael Dell started by presenting some facts: $1.2 trillion dollars spent annually on IT infrastructure. $400 billion on hardware/software, $800 billion on labor and services. The dilemma is that we spend 70% on keeping the lights on, and only 30% on innovation. The desire is to flip that balance (same message that Ann Livermore of HP delivered yesterday). Dell is making a commitment to taking $200 billion out of the $1.2 trillion spend by enabling the efficient enterprise through: standardization, simplification, and automation.

On standardization, Michael discussed the role of x86 hardware and that today, 90% of all business applications are running on x86 hardware. According to Dell’s calculations, databases run up to 200% better on x86 systems than on proprietary hardware. Oracle and Dell are committed to making the technology work harder, not the user.

Moving on to simplification… the theme is pragmatic consolidation. He talked about Dell’s tiered storage capabilities, including iSCSI, solid state disks, and 10 gigabit ethernet. Similar to the opening keynote, he stated that 20x performance gains are possible with solid state storage technology. He then moved onto virtualization, giving examples of 20:1 server consolidation, 50% operational savings, and 1/3 of IT resources freed up for other efforts.

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: Innovation Across the Stack- Thomas Kurian

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

Thomas started off with an overview of the “red” stack (my words, not his) and the major releases that have occurred this year. He’s starting with a video from a fictional company called Avitek discussing the importance of user experience. Ted Farrell then came on stage to demonstrate advances in Siebel CRM and Oracle Fusion in the UI layer. He showed a UI feature he called “carousel” which looked strikingly like CoverFlow in iTunes, some use of JavaFX, mapping technologies, live chat, and more. They demonstrated integration between Siebel CRM and Oracle e-Business Suite (EBS). This continues with the theme yesterday of top to bottom integration.

After the next video, Thomas is now talking about BPM and has David Shaffer on stage to discuss Fusion Middleware and applications. He started with an ADF application on his iPhone showing him an alert, and then went to the Oracle BPM worklist that shows the task required, moving into a visual representation of the flow required. From there, they were able to determine that they needed to go into EBS to remediate the problem. This demo was a bit too canned for me. The process flow shown looked like something a developer should be looking at, not something someone in a support center would be using. David then moved on to show the Oracle Business Process Composer and its support for BPMN 2.0. From there, a composite service could be drilled into, going straight into JDeveloper. Seeing these demos definitely shows me why Oracle’s JDeveloper strategy makes sense, even though it can be frustrating for organizations that only use Oracle middleware, and not Oracle applications. To properly support development and integration with Oracle apps, a very powerful development environment with integration into design-time metadata systems is necessary.

The demos continued with Ingersoll Rand coming on stage for a demo of Oracle BI and its integration with EBS. After that, they moved on to governance, controls, and security. Norm Fjeldheim, CIO of Qualcomm, and Steve Miranda came on stage for the next demo. Through integration with EBS, they demoed how areas of risk can be shown and addressed via Oracle GRC. Next up was scalability and high availability, and the demo started with Oracle Enterprise Manager. Enterprise Manager is being used to show the end-to-end view, highlight hot spots, link to management consoles of WebLogic, etc., and take action to fix. It continued on with operational management (there was a LOT in this keynote). This includes real end user experience, correlation between business and system monitoring, and root cause identification. Marshall Lew from Office Depot came on stage to assist in this demo. I wasn’t aware that Oracle played in the operational management space, so this was new to me. It’s all built from their Enterprise Manager product. If your infrastructure stack is red, this is a nice centralized management system.

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.

Kindle needs an iTunes equivalent

I’m an unabashed Kindle fan, but I’ve come to realize that there is room for improvement. The Kindle needs an iTunes equivalent. Not the store, but the desktop companion application. Clearly, Amazon’s original intent for it was as a book reader. For me, however, the usage parallels that of my first iPod. When the iPod came out, there was no iTunes store, but there was iTunes. You took your existing CDs, ripped them into iTunes, and put the content onto your iPod. While there’s no way to “rip” a physical book onto the Kindle, there’s still plenty of electronic content that I deal with each and every day that I’d love to have on the Kindle. Unfortunately, there’s not a good solution for that. Yes, you can email these documents to Amazon and pay a fee for wireless delivery (not cost effective for as many documents as I’d convert), or you can use a program like MobiPocket Creator or Stanza to convert them yourselves, which frankly, is a pain. What I want to be able to do is just drop a Word document or a PDF into a library in this application, and then the next time I connect my Kindle via USB, have those files converted and placed onto the device.

Why would I want to do this? I receive new documents probably every single day, ranging from 2-3 pages to 20 pages or more. Keeping them on the laptop usually means they don’t get read, and printing them out is a waste of paper, and also likely that they don’t get read, as I don’t have them with me when I have time to read. Putting them on the Kindle would be a great solution for me. Plus, the Kindle allows annotations, so if I need to document something to discuss with others, it can do that for me. If this were possible, I think it would open up the Kindle for the corporate market. If there were ways to tie a Kindle to an analyst firm subscription, even better. Amazon would really need to improve the content management on the device, because one big long list quickly becomes problematic, but that can be solved through software. So, Amazon, when can we see the desktop content manager for the Kindle, or are you leaving this up to a third party to provide?

EA Communications

This seems to be the topic of the week with excellent posts on the subject from both Leo de Sousa and Serge Thorn.  This has been on my to-do list since a meeting with Bruce Robertson where we discussed both my thinking on EA Services and Gartner’s, which also resulted in a blog post from Bruce. In that conversation, Bruce convinced me that communication should be a top level EA service, rather than an implied activity within all other EA services, as was my previous stance.  This was also challenged by Aleks Buterman in our discussions on Twitter.

Bruce’s stance was that communications was essential to everything that EA does.  If your EA team can’t communicate effectively, then their chances of success are greatly diminished.  By defining it as a top level EA service, it emphasizes its importance for not just the EA team, but everyone who utilizes the EA services. 

Given that assumption, what does the communication service look like?  I think Leo gave a great start at a communication plan.  In reality, the EA communication service shouldn’t be very different than any other communication service, the only difference is the subject being communicated.  Therefore, let’s learn from practices of the communications experts.  Leo relied on a communication plan created by a colleague that is used for many things, not just enterprise architecture.  I’m trying a simliar approach, initially based on a template from ganthead.com, but has now been customized quite a bit. In the plan we capture a number of items.  You’ll see there are many similarities to what Leo had to say, plus some additional items I think are important.  The plan is a simple Excel spreadsheet, with each row representing a unique “audience.”  These audiences do not have to be a mutually exclusive, in fact, it’s quite common to have one row targeted at a broad audience, and then other rows targeted at more narrow subgroups.  For each audience, the following things are captured:

  • Questions to answer / Information to present: In a nutshell, what are we trying to communicate to the audience?  What are the two or three key items to present?
  • Sensitivies: This one isn’t on Leo’s, but I think it’s very important.  What are the biases and background that the audience has that may positively or negatively impact the effectiveness of the communication?  For example, if your organization has tried the same initiative 5 different times, and you’re proposing the sixth, you should know that you’re walking into a room full of doubters.
  • Mechanism: How will the communication be delived?  This can involve multiple mechanisms including presentations, podcasts, webinars, blogs, whitepapers, etc.
  • Objective: What is the objective of the communication for the audience?  This is different than the information to present, this instead is the expected behavior you expect to see if the communication is successful.  Obviously, the communication alone may not achieve the objective, but it should represent a big step in that direction.
  • Author(s): Who will create the communications collateral?
  • Presenter(s): Who will present the information?
  • Delivery date(s): When will the communication be delivered, and if it’s an on-going process, at what frequency?  If there are mutliple delivery dates, when will the last delivery occur?
  • Evaluation Method: How will we evaluate the effectiveness of the communication?  There may be multiple evaluations.
  • Follow-up date: When will follow-up occur with the audience to gauge effectiveness and retention?

This may seem like a lot of formality, but I’ve seen the benefits of it first hand, and the risks associated with ad hoc communication efforts.  My experiences with ad hoc have been hit or miss, but when the time was taken to develop a formal plan, the efforts have always been successful.  I hope this helps you in your efforts.

Why I Blog

James McGovern, in one of his parting blogs (only time will tell if that’s really the case or not), asked some questions of me. Here’s his comment:

Todd Biske: I can count the number of peer enterprise architects from Fortune enterprises who are credible bloggers on one hand and I must say that your blog is the gold standard in this regard. Could you make your next blog entry on the topic of why you blog but more importantly provide a sense of why in a way that will encourage some of our other industry peers to come out of hiding? Please also share what other topics are of interest to you besides SOA? Curious to know if you have drunk the Kool-aid on $$$$ ECM technologies that really should cost $ or whether you have ever attended an OWASP meeting, etc?

First, thanks for the compliment. While we definitely have different styles, the fact that your blog exists is a continual incentive for me to continue to do so, as it is a sign that there are practicing EA’s who are also willing to share publicly. Furthermore, your efforts in calling attention to other bloggers through your blogs popularity helped a number of other corporate IT bloggers to build an audience which is critical for keeping the information flowing.

The reason I blog has always been very simple- sharing information. I have a hard time believing that there aren’t other people who are thinking about the exact same problems that I am. There are plenty of paid services that can provide access to “the network,” whether its buying a vendor’s product, paid analysis, consultants, etc. I have no problems with them trying to make a business out of it, but I also think there’s no reason why we shouldn’t be sharing information with our fellow peers for free. While there will always be work that must remain private for competitive reasons, how much of what we do every day really falls into that category? Does my recent post on EA services reveal anything private about my employer? No. Can the comments and discussion in public Internet forums help make those definitions better? Absolutely, and many organizations are already doing this, only through closed, paid networks. These networks provide great information, but you have to pay to join the club. So, that’s a long way of saying that I prefer to be an example of public sharing, and allow people to learn from my experiences in the hope that they’ll share some of their own. It’s been far more giving than receiving, but I’m 100% okay with that.

To your other questions… other topics of interest to me: anything of strategic nature with regards to the use of IT. I’m a big picture thinker, and always have been interested in the application of technology rather than the technology per se. I did a lot of work in usability in my early days for just this reason. I’m also very interested in the human aspects of things, taking a social psychology angle (just heard that term on a podcast and really liked it). Outside of that, the rest of my time revolves around faith and family in one way or another. On ECM technologies, I haven’t had to do a ton of work in this space, but I do know I haven’t drunk any Kool-aid. I’m fortunate to do some work for my kids’ school which has to leverage IT on a shoestring, so I’m able to keep an eye on some less expensive tools, including ECM recently. On OWASP, I have not attended a meeting, but have spoken with a colleague at work who wants to get a St. Louis group established. I will put him in touch with you to get some advice on getting the group going.

James, I hope you continue share your wisdom, and I’m sure you will, even if it’s not through the blogosphere anymore. Thanks for your part in making my blog better and building my audience.

EA Services: Part Two

Jeff Schneider posted the following comment to my previous post, “What are your EA Services?”

Your services feel too ‘responsive’ – like someone has to pick up the phone and call you in order for EA to be valuable. Thoughts?

I was hoping someone would ask a question along these lines, because it’s something I’ve thought a lot about. Services, by their nature, should seem very ‘responsive.’ After all, there should always be a service consumer and a service provider. The consumer asks, the provider does. In the context of an enterprise architecture team, or any other team for that matter, you do have to ask the question, “If no one is asking me to do this, why am I doing it?” Is that stance too theoretical, though?

When I think about this, I think services in this context (ITIL/ITSM) follow the same pattern that can be used for web services. There are services that are explicitly invoked at the request of a consumer, and then there are services that are executed in response to some event. In the latter case, the team providing the service is the one monitoring for the event. If some other team was monitoring for it, and then told your team to do something, then we’re back to the request/response style with one team acting as consumer and the other acting as the provider.

Coming back to the EA services, I think an Enterprise Architecture team will typically have a mix of request/response-style and event-driven services. It’s probably also true that if the EA team is closer to project activity, you’ll see more request/response services done on behalf of project teams, such as the Architectural Assessment Services and the Architectural Consulting Services I mentioned. If your EA team is more involved with portfolio management and strategic planning, then it’s possible that you may have more event-driven services, although these could still be request/response. Strategic direction could be driven by senior management, with direction handed down on areas of research. That direction represents a service request from that strategic planning group to the EA team. In an event-driven scenario, the EA team would be watching industry trends, metrics, and other things and making their own call on areas for research. It’s a subtle difference.

Anyway, I do think Jeff has a valid point, and as part of defining the services, you should classify the triggers that cause the service to be invoked. This will clearly capture whether they are event-driven or request/response. If your list is entirely request/repsonse, that’s probably something to look into. That may be what’s needed today, but you should be practicing good service management and planning for some event-driven services in the future if your team continues to provide value in the organization.

Thanks to Jeff Adkins for the good discussion about this on Twitter.

What are your EA Services?

A week or so ago, I asked about defining on EA services on Twitter. My use of the term services here is in more of the ITIL/ITSM sense, not what typically comes to mind when discussing SOA, but I could have another blog post just dedicated to that subject. I’ve been working to define EA services at work, and it’s been a very interesting exercise, and I had hoped that other EA’s (or former EA’s) on Twitter would have something to contribute.

Something that is a bit surprising to me, is that many IT teams struggle to explain exactly what they do, especially those whose primary purpose isn’t project work. This doesn’t mean that the team isn’t needed, but it does put you at risk of having the team be defined by the individuals rather than by their responsibilities. Depending on who the individual is, you get a different set of capabilities, making it difficult to quantify and measure what the team, rather than the individual does. A conversation with my boss and another team member on a different subject brought up the term “define by example” and we all agreed that it’s usually a bad thing. Examples are very important in illustrating the concept, but they shouldn’t be the definition. The same thing goes for a team. Your team should not by defined by individuals on it, but rather the individuals on it should be providing the defined services.

Getting back to the subject, the initial list of EA services I came up with, and vetted by Aleks Buterman, Leo de Sousa, and Brenda Michelson are:

  • Architectural Assessment Services: The operations in this service include anything that falls into the review/approve/comment category, whether required or requested. Ad hoc architectural questions probably go here, but those are one that I’m still sitting on the fence about.
  • Architectural Consulting Services: The operations in this service include anything where a member of the EA team is allocated to a project as a member of that project team, typically as a project architect. The day-to-day activities of that person would now be managed by a project manager, at least to the extent of the allocation.
  • Architectural Research Services: The operations in this service are those that fall into the research category, whether formal or informal. This would include vendor conversations, reading analyst reports, case study reviews, participation in consortiums, etc.
  • Architectural Reference Services: The operations in this service are those that entail the creation of reference material used for prescriptive guidance of activities outside of the EA team, such as patterns, reference models, reference architectures, etc.
  • Architectural Standards Services: Very similar to reference services, this service is about the creation of official standards. I’m still on the fence as to whether or not this should be collapsed into a single service with the reference services. Sometimes, standards are treated differently than other reference material, so I’m leaving it as its own service for now.
  • Architectural Strategy Services: Finally, strategy services capture the role of architecture in strategy development, such as the development of to-be architectures. If there is a separate strategy development process at your organization, this one represents the role of enterprise architecture in that process.

Now, the most interesting part of this process has not been coming up with this list, but thinking about the metadata that should be included for each of these services. Thinking like a developer, what are the inputs and outputs of each? Who can request them? Are any internal services (e.g. always requested by the EA manager) only, and which ones are external services (e.g. requested by someone outside of EA)? What are the processes behind these services? Are these services always part of a certain parent process, or are they “operations” in multiple processes? How do we measure these services? You can see why this suddenly feels very much like ITIL/ITSM, but it also has parallels to how we should think about services in the SOA sense, too. Thinking in the long term, all of these services need to be managed. What percentage of work falls into each bucket? Today, there may be a stronger need to establish solid project architecture, leading to a higher percentage of time spent consulting. Next year, it may shift to strategy services or some other category. The year after that, the service definitions themselves may need to be adjusted to account for a shift toward more business architecture and less technology architecture. Adjusting to the winds of change is what service management is all about.

So, my question to my readers is, what are your EA services? I’m sure I’m not the only EA out there who’s had to think about this. Even if your EA organization hasn’t, the next time you fill out your time card, think about what “service bucket” your efforts fall into. Do my categories make sense for what you do each week or month? If not, what’s missing. If it’s unclear which bucket something should go in, how would you redefine them? A consistent set of EA service definitions can definitely help all of us.

Build What Sells, Don’t Sell What You Build

I just read the Forrester document, “Inquiry Spotlight: Building An EA Practice, Q2 2009,” written by Gene Leganza and Katie Smillie, with Alex Cullen and Matt Czarnecki, and there’s one line that really stuck out for me.

When creating EA artifacts, you should focus on “building what sells” more than on “selling what you build.”

I think I should take that line and make a poster out of it. This consumer-first thinking is really, really important. I’ve seen too many things that were written for the convenience of the author rather than the consumer, and it never is as successful as it should be. This applies to EA artifacts, to user interfaces, to services, and just about anything else that’s supposed to be consumed by someone other than the person who wrote it. If you don’t make it easy to consume by the intended audience, they won’t consume it at the rate you desire. The trap that you can also fall into is to fail to recognize that you have more than one audience. If you assume a single, broad audience, then you wind up with a least common denominator approach that frequently provides too little to be useful to anyone. While some “100-level” communication is a good thing, it must be followed up with the “200-level” and “300-level” communication that is targeted at particular audiences and particular roles. For example, if you’re planning your communication around an enterprise SOA strategy, you may create some 100-level communication that is broad enough to wet the appetite of project managers, organizational managers, and developers, but not enough to tell any of them how it will impact them in detail. Follow that up with pointed conversations targeted specifically at the role of the project manager, the organizational manager, and the developer to get the messages across to them, and them only.

Finally, getting back to EA artifacts, consider not just the roles, but also the context in which the artifacts will be used. If the artifacts are used in project activities, then structuring them so the appropriate information is provided in the appropriate phase of the project is a good thing. Organizing the artifact to where people must hunt all over for the information they need at a particular point in time is not a good thing.

Once again, take Gene and Katie’s words to heart: Focus on building what sells more than selling what you build.

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.