The State of the Scripting Universe
Posted by Shahid N. Shah in Uncategorized on September 5th, 2008
As architects we’re routinely asked about the “best tool for the job.” More and more these days the answer is a scripting language like Perl or Ruby — and, without a wink or cringing about it. Even as little as ten years ago those of us who liked scripting languages only recommended it for small utilities or daily script work — however, more and more these days scripting languages are being used to deliver entire services in a SOA or WOA environment and even build complete applications. I still think that scripting is for specialized domain-specific uses but others believe that scripting can be used for general-purpose use cases, too.
Check out this CIO Magazine article “PHP, JavaScript, Ruby, Perl, Python, and Tcl Today: The State of the Scripting Universe“. It’s got some good content and thoughts from the creators or managers of the projects that the scripting languages come from.
Web Oriented Architecture (WOA) succeeding SOA?
Posted by Shahid N. Shah in SOA on September 4th, 2008
Many service-oriented architecture (SOA) efforts in the government and elsewhere are not getting off the ground quickly enough to be worth the ROI. They are falling prey to the same problems as other top down, centrally driven projects that SOA was meant to solve and promises that were made.
Large complicated solutions are always harder to implement and put into place versus smaller, simpler projects. This is probably why new web-oriented architecture (WOA) efforts are seeing the light of day. Because they are smaller, use RESTful capabilities built into HTTP, and can be enabled in existing web applications with minor alterations.
Instead of designing solutions around higher-level business services (like in SOA) the WOA approach is to create simple resources that serve up some useful data. The WOA approach is faster, more agile, and probably more immediately useful but does have the drawback of not being a “business service” as much as a collection of data or other resources. Of course, many of the business services that architects think they are creating are also just lookup services.
So, the question is — is WOA succeeding SOA? Are any of you doing anything for WOA or are the reports of SOA failures over hyped?
The value of architecture artifacts
Posted by Shahid N. Shah in Methodologies & Frameworks on August 29th, 2008
As business or technology architects we all create tons of artifacts — documents, diagrams, whiteboard scribbles, and presentations. The question I and a other architects were musing about this week was “what is the value of all this stuff we create?” How much of this stuff is shelfware and how much is truly useful? Some of us think that the federal acquisition process demands it but the content is not accurate and might even be irrelevant.
One of the discussion members said that, from a programmatic perspective, architecture artifacts can, if done appropriately: (1) be of very high value in communicating with oversight officials (and that brings funding), and (2) bridge programs for interoperability.
I tend to think that most of the artifacts we generate are for helping ourselves understand what we’re doing and convey our principles, concepts, designs, and plans for others to better understand what we think we know. Ultimately, even if it’s shelfware it seems that all architecture artifacts have some value — even if it’s just historical value. The key is that we don’t create artifacts for the sake of those artifacts but for the sake of increasing communications.
What are your thoughts on architecture artifacts? What rules do you use to create “just the right amount?”
OMB Mandates Secure DNS by end of ‘09
Posted by Shahid N. Shah in Regulations & Guidance on August 28th, 2008
Karen Evans sent out the new OMB Memo 08-23 which requires secure DNS. Agencies need to submit a plan by September 5th for how they can plan the switchover by the end of 2009. Here are some snippets of what OMB is mandating (comes from the memo):
The Federal Government will deploy DNSSEC to the top level .gov domain by January 2009. The top level .gov domain includes the registrar, registry, and DNS server operations. This policy requires that the top level .gov domain will be DNSSEC signed and processes to enable secure delegated sub-domains will be developed. Signing the top level .gov domain is a critical procedure necessary for broad deployment of DNSSEC, increases the utility of DNSSEC, and simplifies lower level deployment by agencies.
Your agency must now develop a plan of action and milestones for the deployment of DNSSEC to all applicable information systems. Appropriate DNSSEC capabilities must
be deployed and operational by December 2009. The plan should follow recommendations in NIST Special Publication 800-81 “Secure Domain Name System (DNS) Deployment Guide,” and address the particular requirements described in NIST Special Publication 800-53r1 “Recommended Security Controls for Federal Information Systems.”
I do applaud the new requirement but it seems like having less than 15 months to make all this happen seems a little aggressive; I hope we all can pull it off. By pushing secure DNS at the government side the rest of the commercial sector might follow suit soon, too.
GAO reports on Agencies’ rebaselining projects
Posted by Shahid N. Shah in Methodologies & Frameworks, Project Management on August 26th, 2008
A fellow EA at the Army sent me a link to the GAO’s recent IT report entitled “OMB and Agencies Need to Improve Planning, Management, and Oversight of Projects Totaling Billions of Dollars“. The study’s introduction says it was needed because:
…the Office of Management and Budget (OMB), which plays a key role in overseeing the federal government’s IT investments, identifies major projects that are poorly planned by placing them on a Management Watch List and requires agencies to identify high-risk projects that are performing poorly (i.e., have performance shortfalls). Having accurate and transparent project cost and schedule information is also essential to effective oversight. At times, changes to this information—called a rebaselining— are made to reflect changed development circumstances. These changes can be done for valid reasons, but can also be used to mask cost overruns and schedule delays.
It’s worth reading and getting our hands around what the legislative side thinks about our IT projects. Their summary indicates rebaselining is a major issue:
In its rebaselining review, GAO reports that 48 percent of the federal government’s major IT projects have been rebaselined for several reasons, including changes in project goals and changes in funding. Of those rebaselined projects, 51 percent were rebaselined at least twice and about 11 percent were rebaselined 4 times or more. In addition, while the major agencies have all established rebaselining policies, these policies are not comprehensive. Specifically, none of the policies were fully consistent with best practices, including describing a process for developing a new baseline and requiring the validation of the new baseline. Agencies’ policies varied in part because OMB has not issued guidance specifying what elements these policies are to include. In its report, GAO makes recommendations to OMB to issue guidance for rebaselining policies and to the major agencies to develop comprehensive rebaselining policies that address identified weaknesses.
Not exactly a damning statement but certainly something we should be mindful of as we look forward to our new EA submissions in the figure. With some changes expected with the coming presidential transition it’s unclear what OMB’s direction might be but even if specific policies aren’t announced, if we just use standard best practices on our side we should be ahead of the curve.
Time for a Federal Cloud Architecture
Posted by Shahid N. Shah in Cloud Computing on August 24th, 2008
As most of us are already aware, there are many commercial cloud computing initiatives underway. Amazon, Google, Microsoft, are all looking to make their claims in the cloud space with IaaS (infrastructure as a service) and PaaS (platform as a service) strategies.
Most of us as federal architects of course don’t really have the ability to use or consume any of these cloud architectures since they are not at least FISMA compliant and they are generally not secure for us to use. The services can’t be logged and reliability is questionable.
However, if some of us got together (maybe with the eGov Infrastructure Line of Business) and figured out how to create a Federal Cloud Computing strategy I’m sure we’d be able to make secure, auditable, platform agnostic, reliable, and portable clouds for use by agencies. This way we could make SOA a reality and allow our architects to take advantage of IaaS and PaaS capabilities that we could build out.
Updated Sept 5, 2008: I just saw this press release — Apptis Teams with ServerVault to Launch the Trusted Cloud Computing Environment for the U.S. Federal Government. They claim that their “Secure Platform Complies with Federal IT Regulations and Helps Agencies Achieve Required Functionality Faster”.
Comparing Top EA Methodologies
Posted by Shahid N. Shah in Methodologies & Frameworks on August 23rd, 2008
I’ve been doing EA for years and one of the most common questions I’m asked from young business analysts and aspiring architects is “what is an EA methodology?” There’s no easy answer to what EA is because it means so many different things depending on the intended audience but there are common methodologies that folks are likely to see in various settings.
Last year Microsoft published Roger Sessions’s white paper called “A Comparison of the Top Four Enterprise-Architecture Methodologies“. It’s worth reading.
It’s harder getting out than getting in - improve your RFPs
Posted by Shahid N. Shah in Decision Making on July 20th, 2008
We’ve all seen it: we spend weeks or months in the “sales and demo cycle” for our applications. If we’re lucky we consider all workflows, if we’re even luckier we test drive the UI and make sure training goes smoothly, if we’re smart we also try to ensure that deployment will be easy. However, what we all seem to forget is to figure out how to get out of an application or system after it’s been installed for a while.
Why is getting out important? Because every application becomes “legacy” sooner or later. Every system will be replaced or augmented at some point in time. The cost of acquisition (”barrier to entry”) is well understood now as something we need to calculate. How about the barrier to exit or switching cost? Do we calculate that when we decide what systems to purchase? Why not?
If you can’t answer the “how, in 24 months, will I be able to move on to the next-better technology or system?” question then you’ve not completed your due diligence in the sales cycle.
When preparing an RFI or RFP, ask vendors specific questions about how easy it is to get out of their technology (rather than just how easy to it is to deploy and interoperate). Put in specific test cases and have your folks consider this fact when they are looking at all new purchases. Here are some specific factors to consider:
- Do you own your data or does the vendor? Make sure it’s explicit in your RFP.
- Is the database structure and all data easily accessible to you without involving the vendor? If only your vendor can see the data, you’re locked in so be very wary. In the RFP make sure it’s clear that you want this documented and provided to you.
- Are the data formats that the system uses to communicate with other vendors open? If not, you don’t own your data. Make sure the RFP explicitly states you want the data formats.
- How much of the technology stack is based on industry standards? The more proprietary the tech, the more you’re locked in.
- Are all the programming APIs open, documented, and available without paying royalties or license costs? If not, when you try to get out you’ll pay dearly.
If you have other considerations, share them here.
Traits of good architects and technical leaders
Posted by Shahid N. Shah in Decision Making, Leadership on July 20th, 2008
Many of my younger colleagues often ask about what some of the most important leadership aspects are for technical managers like team leads or architects. There are no hard and fast rules but here are some things I’ve learned over the years:
- Make Decisions. This is one of the most important aspects of leadership — just making a decision and not analyzing for weeks or months. No amount of evidence or information will ever “be enough” and at some point you’ll need to make a decision. Your team can see if you are timid or if you take risks. Leadership is about decision making and if your decision making skills or risk taking ability are limited, don’t bother trying to lead. I’ve seen many architects and so-called “team leads” that try to get their bosses to make their decisions for them so they don’t get in trouble for making “the wrong ones”. Big mistake.
- Lead by Example. Leadership is about direction and if you want to lead, you’ll need to make sure you take charge and establish that you know where you want to go. But, be prepared to demonstrate that you do what you ask your team to do. If you ask everyone else to do something but don’t do it yourself, your team will lose respect.
- Be transparent. You work with bright people and although they may not be your equals in experience or knowledge, they will know when you are making decisions based on whim or reason. If you can’t explain your decisions in a way that your team can comprehend then you’re not a good leader.
- Mentor. Good leaders create the next group of leaders, not just bark orders. If you’re not regularly mentoring and training, you’re not doing your job. And, if you mentor well you can let your team make many of the decisions without you and you’ll be able to trust that their decisions will be as good as yours.
- Be inclusive. You’re the leader and can make all the decisions and everyone knows that. But, if you’re not including input from everyone you’re losing valuable data and a chance to build a cohesive team.
If you can’t repeat it, don’t bother automating it
Posted by Shahid N. Shah in Project Management on July 20th, 2008
There’s been plenty of discussion in both literature and general media about “most software projects failing.” There are plenty of reasons for failed projects: from inadequate requirements gathering to poor project management to plain incompetence. Some of the problem starts at the C-Suite where projects are actually identified and started — for asking to automate (presumably with software) something that maybe has no business being automated.
My simple advice to most architects, CTOs, CEOs and CIOs about project management starts with a question: can you methodically and manually repeat the thing you are trying to automate? If the answer to that question is “no” then no PMO, no project management technique, not even the smartest most talented people in the world can help automate something that can’t at least be repeated consistenly manually.
This advice of asking a simple question about repeatability might sound so obvious as to not even bother asking it but it becomes perilous not to do so. At the heart of most failed software automation attempts is a failure to understand the workflow and gather the right requirements. That’s pretty easy to figure out. What’s not so easy to figure out is: why is the workflow so hard to gather requirements for? It’s probably because the workflow, while it seems consistent at the high level, isn’t repeatable enough consistently to describe in software. Perhaps parts of it are, but maybe the entire workflow isn’t.
So, as a senior executive that may not be leading the project, but may be greenlighting it, what you need to do before making a decision is have your project managers describe that they can clearly repeat (manually and consistently) what they are trying to automate. If not, get the process engineering guys in there to work on the process before the geeks get in there to work on the technology.
-
Who's Blogging Here
The founder of this blog is Shahid N. Shah, CEO of Netspective. Please help continue our conversations by commenting on any posts. If you'd like join and start blogging, just create an account and begin sharing your thoughts immediately.
Recent Comments