29.08.2007
Performance Measures, Processes, SOA, Strategy
After some time thinking about my last post about EA being dead, I decided to resurrect it and marry it up with three other diciplines that I have been working in for the last 10 years; that being Strategic Management, Business Process Management and (now) Service Oriented Architecture. If you’re going to use the word “enterprise” in the context of architecture, then doesn’t it make sense to include the WHOLE enterprise?
So, the result of my thinking is shown below – I’m calling it EA v2.0. When you look at the diagram, the one thing to pay attention to is the relationships between the layers of the model, and not so much what’s in each layer. The fact is that fairly mature methodologies exist for every layer. This model is my attempt to build better understanding about the linkages BETWEEN the layers. In other words, there are a lot of models out there for conducting strategic planning, business process modeling, workflow management, and technology archtiecture; however, I have yet to find anything that explains in simple terms how all this crap ties together in a way that organization executives can understand.
So, take a look at my EA v2.0 reference model below and tell me what you think….r/Chuck
04.08.2007
SOA, Technology
It’s impossible to goto a law enforcement information sharing conference these days and NOT hear about this thing called a “Service Oriented Architecture (SOA).”
One of the big questions I hear asked is “How do I go about implementing an SOA?”
If you do a google on “Service Oriented Architecture” (use the quotes to be fair) you will find that Google lists 11,500,000 documents related to SOA. If you go to Amazon.com and do the same search, you’ll see 609 books on the subject.
The majority of these documents and books basically tell you to do the same five things to transition your organization’s information technology infrastructure to one based upon SOA principles: 1) have governance, 2) have a roadmap, 3) take one bite at a time, 4) train your staff for SOA, and 5) use open standards.
I don’t want to dispute or debate any of what they have to say; I’m certain it’s all good. Instead what I thought I would do is mix things up a bit and share with you what I consider to be the top ten things you can do to really screw-up up a move to SOA. Let’s begin…
- Run and tell your CEO or Agency Executive that SOA is going to save the day by solving all of their IT problems. Tell them it’s easy. Show them the glossy brochure your vendor gave you; that’ll really impress them.
- While you’re at it, tell them that you won’t need all the money they gave you this year. With all this stuff about reuse you’ve been reading, SOA is going to save them a boatload of money.
- Treat moving to SOA just like any other IT project. It’s still just hardware and software, no use getting all excited. You just need SOA requirements, and then it’s coding, testing, and deployment.
- Keep the “operator” folks away from the effort. You know that as soon as they get their fingers on the project, they’re going to want to muck it up with business needs and process diagrams.
- Plan to convert all of your applications to SOA all at once. In fact, go ahead and announce the date you’re going to shut-down the mainframe. That will illustrate your commitment to SOA.
- Inform the mainframe COBOL programmers and DB2 admins that they need to find new jobs and then immediately put in a request with HR to hire a dozen XML and SOAP programmers.
- Don’t waste your time on developing a plan or roadmap (aka enterprise architecture) to move to SOA. No one really reads all those documents; and after all, you have the functional specifications from your existing applications.
- Immediately go out and buy an ESB from your favorite vendor. Don’t know what one is? Don’t worry, your vendor will know, and they will be glad to come in and just plug everything together. SOA, done.
- Also make sure you develop as many services as possible. You’ll be able to justify your move to SOA based on the number of services you develop; the more you develop, the better you’ll look.
- Finally, if all else fails screw-up up your SOA project, then try this – take your best techie and put them in charge of the effort, then sit back and enjoy the fun!
I hope that you enjoyed my little diversion from the serious side of SOA, and I also hope that you were able to see through my satire and recognize some of the silly things organizations do to torpedo what should be a fun and beneficial experience for every organization.
BTW, no vendors, programmers, or other techies were actually harmed in the writing of this blog, at least none that I know of.