SOA
02.01.2009
CJIS, data sharing, Evaluation, Information sharing, law enforcement, Law enforcement information sharing, LEIS, Performance Measures, Processes, public safety, SOA, Strategy, Technology, Uncategorized
Tom Peters liked to say “what gets measured gets done.” The Office of Management and Budget (OMB) took this advice to heart when they started the federal Performance Assessment Rating Tool (PART) (http://www.whitehouse.gov/omb/part/) to assess and improve federal program performance so that the Federal government can achieve better results. PART includes a set of criteria in the form of questions that helps an evaluator to identify a program’s strengths and weaknesses to inform funding and management decisions aimed at making the program more effective.
I think we can take a lesson from Tom and the OMB and begin using a formal framework for evaluating the level of implementation and real-world results of the many Law Enforcement Information Sharing projects around the nation. Not for any punitive purposes, but as a proactive way to ensure that the energy, resources, and political will continues long enough to see these projects achieve what their architects originally envisioned.
I would like to propose that the evaluation framework be based on six “Standards for Law Enforcement Information Sharing” that every LEIS project should strive to comply with; they include:
1. Active Executive Engagement in LEIS Governance and Decision-Making;
2. Robust Privacy and Security Policy and Active Compliance Oversight;
3. Public Safety Priorities Drive Utilization Through Full Integration into Daily Operations;
4. Access and Fusion of the Full Breadth and Depth of Regional Data (law enforcement related);
5. Wide Range of Technical Capabilities to Support Public Safety Business Processes; and
6. Stable Base of Sustainment Funding for Operational and Technical Infrastructure Support.
My next step is to develop scoring criteria for each of these standards; three to five per standard, something simple and easy for project managers and stakeholders to use as a tool to help get LEIS “done.”
I would like to what you think of these standards and if you would like to help me develop the evaluation tool itself…r/Chuck
Chuck Georgo
chuck@nowheretohide.org
www.nowheretohide.org
04.02.2008
SOA
It’s been a while since I’ve added anything to my blog. Largely because I’ve been engaged in a wonderful project to help a State Police agency develop an EA and a Service-Oriented approach to replacing their Hotfiles and Message Switch. I’d be interested in learning about anyone else engaged in a similar effort, or ayone developing a law enforcement or justice Service-Oriented Architecture (SOA)…Please email me at chuck@nowheretohide.org.
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.