Oracle Corporation :: Oracle Announces General Availability of Oracle(R) Business Process Analysis Suite: Their suite is built on the IDS-Scheer ARIS Platform suite of tools we are using as our standard business architecture platform, including process modeling. I'm hoping that we can pull the Oracle PeopleSoft Enterprise business models into the enterprise-wide repository and utilize these standard processes as a framework to build our unique, value-added processes. And also integrate them with other processes that utilize PeopleSoft resources. Should be interesting.
I'm a tad bit peeved at the part of the announcement with some details of the suite's components, including the modeling piece called Architect (the standard ARIS tool is called Business Architect):
A standards-based tool for process modeling that supports standards-based notations and templates including Business Process Modeling Notation
If I'm not mistaken, I think that BPMN is NOT used to document the Oracle application business processes...it uses the ARIS de-facto standard EPC for that. And I've written before about my nonplused attitude toward ARIS's weak support for BPMN...maybe they've done something wonderful with it in the Oracle implementation and we'll see that in the product soon.
UPDATE: AMIS Blog has news from a demo of Oracle BPA, which was very informative, including their hierarchical organization of business processes, something I'm struggling with for our own enterprise business process architecture right now: "Oracle BPA recognizes four levels of decomposition: 0=Industry Level or Process Category (SCM, HRM), 1=Business Process (Inventory Management) ,2=Detail Business Process (level of SOA Services), 3=Activity Model (BPEL) and application specific.". I would love to see a demonstration of this product, just to get a look at how they structure their organization of business processes...can anyone get us a demo?
UPDATE 2: Here's an Oracle BPA datasheet (PDF), with too-small graphics, but enough of a view to confirm that they are using the ARIS EPC modeling notation for their business process models. This might make it even more instructional for us building out our BP architecture since we could begin looking at integration with Oracle's standards since we would like to incorporate their HCM process models (supported by their PeopleSoft tool).
Making sure we correctly design and maintain the relationships between the 'pieces' of our business and IT infrastructure are the jobs of Enterprise Architecture (EA) and Configuration Management (CM). On recent work engagement, we recently released a couple of processes to maintain Documentation and Software / Hardware pieces (called Configuration Items or CIs in the CM world), so I've started to learn something about this process area. A meeting last week touched on potential integration points between our Enterprise Architecture (EA) modeling tool, ARIS, and the soon to be coming-online Configuration Management Data Base (CMDB) in Remedy. (BTW...EA includes Business Architecture, which is where we're using ARIS the most currently and is my main focus these days). As I've pondered this a bit since then, there is a lot of overlap in the core data maintained in both the Enterprise Architecture and Configuration Management process areas...these Configuration Items. EA seems to be concerned with designing these CIs (which include business processes CIs as well as the hardware and software CIs that support those processes) and the relationships between them (with the relationships being the important thing) and CM is concerned with communicating the change in t hese CIs as they move from development into production environments (making sure everyone is aware of the impacts of CI change and correctly plans for it). ARIS provides a tool to graphically build relationships between CIs including new potential CIs and existing CIs (re-use is important!). Remedy and other CMDB tools serve a similar role, although they are more concerned with maintaining those existing CIs and relationships that exist in the currently deployed environment (as opposed to the in-design / proposed / nirvana CIs and relationships built during the development cycle).
I say all of this to let those of us interested in EA and CM know that there are a couple of bloggers I've recently discovered taking about this same thing.
Serge Thorn's IT Blog covered a late-April CMDB vendor initiative (BMC, IBM, HP) in a post a couple of weeks ago...an excerpt:
"Very often information is spread among various sources and no standards exist on how to exchange meta data from all these potential sources of CMDB information. Today, the CMDB interfaces that exist are all proprietary, which is the problem that this group wants to tackle."
And the ServiceCatalog blog chimed in (and connected us to Serge), linking integration of islands of CM information (from EA and CM efforts, for instance) via standards (or the lack thereof):
"Serge brings an excellent point on CMDB integration -- standards are missing. And no market really grows without standards. "
These are a couple of bloggers to keep track of...so I've added them to the blogroll.
Attending the MetaGroup Enterprise Planning & Architecture Strategies Workshop for the next couple of days here in beautiful San Diego! I'm the hometown boy, along with one of the instructors from MetaGroup, Robert Handler. It's a group of about 20 taking the workshop.
We'll see how to go about blogging this so it might be of interest to other IT and business folks.
Enterprise Architecture is a planning discipline.
Architects need to have a compeling story as to why EA is needed and what it involves. How to sell it to Executive Management. Economics squeezing IT to must-do only. Utilizing IT as competitive weapon. Regulation, SOX. Dynamic M&A. Need for enterprise agility (enabled by architecture).
Challenge: Business and IT think different things for 'model': Business - spreadsheets, IT - flowcharts / swim lanes.
Challenge: Business has cheap, usable software, so why can't IT deliver cheap usable solutions.
Sell: Direct linkage between business and IT PEOPLE reduces business problem recognition time for the entire enterprise.
Siebel Systems - Events - Siebel CIO Shares Best Practices for Release Management
I'm hoping to learn more about Release Management, since it's a discipline I haven't really had an opportunity to work in or explore, despite many years in IT. It seems to he really necessary to control change management in both business process and IT infrastructure.
Recap: The presenter didn't really give many details on the nuts and bolts (coordinating development cycles with release cycles) of how RM happens at Siebel. What was impressive though was his imersion (sp?) in what the key KPIs of Siebel are...which really does show alignment of IT with business.
Continue reading for what I blogged...
RM and reduced IT complexity can improve agility in that you only have implementations to change when you want to change.
Best RM Practices...
RM KPIs...
Real Big (Elephants) and Real Small (Mice) projects present their own problems in relation to RM. You want ' Big Cats'...big enough to make an impact but not too small to go unnoticed.
60-day Drumbeat: Coordinated release, mapped out for each IT Application AND across applications.
Q: How are Key Initiatives for the year determined? How is it decided what goes into a release? A: Top 12-15 executives yearly meet (3 days) to discuss trends, cust sat, etc. Each organization then puts up 12-month rolling plan, which is then communicated to entire staff who then offer what changes will need to be made to meet those plans.
They communicate the release schedule to all employees via their internal portal.
Q: Accomplishment in 2003 slide: How does RM impact these Metrics and Improvements? I'm not quite getting it. These seem like results from the enhancements released, not a result of RM. Maybe I'm being dense.
They have IT Program Managers who work with their 'customers' to maintain the business process improvement maps. Maybe this is their way to get their priorities.
Maybe it's just me, but there is a lot in this presentation, so far, about Siebel and how they measure success than about Siebel's release process. It does show that their CIO has a pretty good handle on what makes the business tic and what his internal customers need in the way of data / analytics, but let's see if this knowledge of the business directly impacts their RM process and strategy.
Upgrade Frequently: They upgrade their infrastructure (Siebel products, 1 instance over 2 load-balanced data centers) up to 10 times a year, which is asynchronous to their 60-day business process improvement releases.
Communication Before / During / After each Release helps smooth the change management.
World-class support, both self-service (FAQ, 2-minute training) and help desk, is key to getting through each release.
Siebel is starting a Application Management Service that will offer their best practices as a service to customer.
Just read a great definition of the role of the EA team in META Group, Inc. - Enterprise Architecture: Answers You Should Have (Meta Account Required),
"EA provides guidance for the selection, creation, and implementation of solutions and related technologies within the context of requirements to meet business strategies."
I'm always looking for these one-liners that work in presentations. And actually, this Meta Practice (EPAS Practice 2110) is good for all kinds of answers to typical questions I've gotten about EA.
Another curious thing I've been thinking about is writing about and linking to things I read by Meta which I know others will not have access to. Will this alienate readers? Will this open up discussion on Meta articles to a community that does have access and wants to write / communicate about it?
On another Meta website note, they do a horrible job of hyper-linking in their documentation on the website. They rarely, if ever, link the numerous references to other Meta Practices / Deltas / Etc. in their documents, leading to frequently frustrating searches and text scanning to find the actual referenced document. Embrace the web!
There are several very similar reports on the recent GAO report on the Department of Homeland Security's Enterprise Architecture Efforts To Date (Full Report, PDF, 15.3 MB), essentially saying that there are holes in version 1 of the DHS EA, with DHS acknowledging as much but stating that this was time-constrained first attempt (DHS IT budget due 4 months after agencies creation) which layed the groundwork for the next iteration due Sept, 2004. Having a little bit of ground-up EA work under my belt now, I can imagine how hard it would be to produce almost anything without major holes in 4 months.
One major thought this brings to me is the importance of Enterprise Architecture for organizations expecting to grow through merger and acquisition. You must be able to quickly compare the Business, Information, and Technology reference models of both entities to determine the fit and gaps to make good decisions as to m&a viability. EA Programs should provide these models.
Back to the story, the best of the articles on this recent report was Dan Verton's Computerworld one that added in the context of a July, 2004 report from the DHS inspector general stating the EA inhibited position of DHS's CIO, Steven Cooper, seems to be starting from,
"Cooper "is not a member of the senior management team with authority to strategically manage department-wide technology assets and programs," the inspector general's report said. It added that there is no formal reporting relationship between Cooper and the CIOs of major DHS components."My limited experience to date is that unless the CIO (or whoever is running the EA Program, and MetaGroup says this is still the CIO in most orgs) and their EA team is not deeply embedded in the senior strategy setting group in the company, then holistic EA Programs, which include the Business Process and Information Flow /Security knowledge DHS EA V1 got dinged on in the GAO report, are truly going to be disadvantaged and not aligned with the vision of enterprise.
ITM launches integrated suite to manage the business of IT - Computerworld
The ITM Business Suite is a set of five modules designed to help IT executives manage vendor relationships, technology project portfolios and the process of aligning internal IT skills with business needs. Mountain View, Calif.-based ITM began shipping an IT governance and compliance management module, which integrates with other modules that are already shipping, and formally unveiled the entire suite in its announcement.
This dovetails with something I've been thinking about a lot recently: Where are the business / information / application / technical architectural artifacts (models, processes, etc.) for an IT shop? Or, more pointedly for us here, for an Enterprise Architecture Program Office? I'm talking about using the same type of architectural artifacts to describe your IT / EA efforts that you would use when describing other, more business-core value chain processes and the IT that supports them. Having this kind of back-up to explain your EA efforts would have the additional benefit of educating your business process owners and data stewards on EA process and it's utility for them. Selfishly, having EA process models and artifacts would make the process of 'doing' EA a whole lot easier.
I would think that the IT / EA models would need to be available for a company like ITM to build their solution.
Enterprise Architect - Agile IT Needs Agile Technologists (free registration required): Jeff Tash walks through a 2X2 matrix he calls the IT People Personality Profile, where agility is the ultimate state of being (and exhibited by a personality class he calls 'agiles'),
What are the characteristics of agiles? They invariably strive to deliver the simplest solutions possible that can meet all the requirements. Simplicity is paramount. So too are standards and modularity. Agiles possess the skills and talent needed to be able to look at both sides of a module's curtain—its internals as well as its externals. Additionally, agiles naturally solicit constant feedback from stakeholders.
I'd put myself somewhere between the Big Talker and the Geek right now. But it's all too obvious that Business thinkers with IT smarts are going to both be in demand, more likely to provide value to their businesses (and IT departments), AND more likely to have a stateside job in the future.
From The Open Group's (Enterprise) Archicture Framework efforts comes Tools for Architecture Development, with a nice set of criteria for evaluating EA tools. My first thought was to answer the criteria questions in the form of requirements and see where that gets me.