Build Vs Buy and more...

I honestly believe that the way Information Technology is done is becoming archaic. For example the typical Software Development Lifecycle (SDLC) is still geared towards to client-server based technologies. Can we say Visual Basic 6, FoxPro, Sybase with back-end relational databases in Oracle, SQL Server, Access? Unfortunately working in the Enterprise space, I have realized that businesses don't want to build every application they desire. There are Custom Off The Self (COTS) software which can be configured to a point where it can used out-of-the-box. The big question in the Enterprise is Build verse Buy. This means do we build the application or buy the application and then use it with mininal configuration. Enterprise Architecture expands the Build Vs Buy problem to Build Vs Buy Vs Reuse functionality from existing applications. In theory this sounds great however there are drawbacks going the enterprise route. There is greater dependency on the enterprise for reuse functionality from existing applications. However if the enterprise is not mature enough then we have to go the "Silo'ed" route since silos impede information flows and exchange but they also protect the systems and programs from risks in an immature enterprise.

In the end, enterprise level IT is good however it is bad if the enterprise level IT is extremly immature. Do we trust our neighbors or do we trust ourselves?

Wave needs work

I finally got my account on Google Wave "Preview" version a few weeks ago. I invited bunch of techie geeks like myself and now we wave. Right?! Wrong!!!! People just don't know how to use it. Wave's email doesn't work. So if you want to email me at enoch.moses[at]googlewave.com then it will get bounced back. There attachments functionality does work yet . I tried sending a descent sized PowerPoint slide deck and I believe it is still loading. Wave folder functionality doesn't work. I guess most of the stuff doesn't work because it's a "Preview" version. I would rank Google's "Preview" version as Oracle's "Production" version. Stuff is supposed to work but it simply doesn't.

I do like the concept and I tried to wave but no one waves back because you really cannot wave. Not even blip well. So get an account and be patient.

Goodluck!

Waving looks good

A week ago, I got a developer account to Google Wave and I am informally testing the application with the accounts they have provided me. It looks good. The concept is simple and a powerful one. A wave is composed of wavelets and wavelets are composed of blips. A simple chat entry, a sixteen page blog entry or an email entry can called a blip. A collection of blips can be captured as a wavelet and a collection of wavelets can be called a wave.

So how is it powerful? It's a great way of organizing information since all of the relevant information for the relevant context are tied together. Currently it is hard to follow emails. For example I get emails from Sender A, who wants to know what I would like for take out, are interspersed with emails from my boss who wants to know the status of my IT projects. The tone and formality of the two email threads are different and it would take me more time to adjust to the "lingo" of the different emails. Recently I am slowly switching my email from Yahoo to Gmail because I like the way Gmail organizes their information.

What I am really excited about Google Wave is for enterprises to mine the data. Imagine tagging the wave and sub taggine the wavelets. Wow! The possiblities are endless! Can we use this model in organizing our Enterprise information?

One thing I don't like about the way it is set up right now is that their emails and waves cannot be viewed in the view. It makes the UI confusing and may confuse some users.

Need a Reference

Yesterday my colleagues and I were talking about Enterprise Architecture (EA) isn't just about classifying metadata but rather it is more than that. I agree that statemenr. By classifying systems, processes, data, applications, resources, technologies and other aspects of your Enterprises, we begin to understand our enterprise but it also defines a reference point from where we can understand the architecture.

Defining the reference point is key but how do we define it? Usually having some requirements that the architecture is trying to address or solve is a great place in defining your reference point. If we are trying to optimize the inputs and outputs of a system then the architecture is going to focus on the inputs and outputs of a system rather than the internals of the systems. After defining where the reference point is, we need to define the reference point. This is not a easy task since the point could a be a subsection of a system (compononet), type of of subsystem (aspect) or a combination of (collection of components or aspects). A good starting point is have your original requirements and now you look at various architecture frameworks to see if these frameworks meet some if not all of requirements. You can also create your framework by stitching together a collague of frameworks. The secret ingredient in selecting your framework is to understand if they really meet the requirements and you, as an architect, can defend your architecture.

These principles are true when you are designing a complex ontology, a metamodel or even a process. In data architecture, we can literally derive infinite relationships between data entities and attributes but in the end does your data architecture must meet the requirements and address the problems. Data relationships can jusitified in a relational database model, metamodel or a class model however all these models should compliment each other and should not contradict each other. To understand if these models are truly complimenting each other and not contradicting each other, you need to have a reference point. The reference point should address the following:

• Does the Architecture address the requirements?
• Does the Architecture capture granularity at the correct depth?
  
• Does the Architecture validate in various use cases and scenerios?

Hope this blog blurb helps you to be a better architect.

Essence of IT

Last week I got into a discussion where folks were defending a SDLC process and stating that the process is great however the practitioners were not good in implementing the process. Hold On! Practitioners are not good in implementing a process? Can we ask a junior programmer to implement best practices like design patterns and ask him or her to code to the Model View Controller (MVC) paradigm? I, personally, expect a junior programmer to create a class (sorry using Java lingo since I work with Java) and to implement a driver method in "public static void main (String[] args){}" where the programmer will write multiple lines of code starting with System.out.println.

My big problem with the statement, "the process is fine but the practitioners are not", is that in the short term it is easier to change a process than to change human resources. If you state that the process is fine but the practitioners aren't then it is time for you to move to the white ivory tower in the IT Neverland and think why isn't anyone coming to the tower. The process maybe fine however if no one is using it then it is time to alter the process, get people to use the process and slowly but surely move the process to its original state. If people think that the SDLC is too complicated then simplify it and get project managers (PMP certifcated or not) to start using it. Get them excited and let them suggest changes in improving it. This way they think they are the agents of change but it infact they are maturing and appreciating a well defined process. This is of course that the practitioners do know something about their domain. If you gave me a copy of Microsoft Project when I was a freshman in college and ask me to manage a $250,000 project with 3 developer then I would now say no process would have helped me since I was clueless. If a person is in a leadership role in a IT department then he should know something about the IT domain like system development. I am not going to ask my wife to lead a system development project since she has never been associated with IT systems other than using the internet.

In conclusion, the essence of IT is the people who work in the IT department. Lets respect them and give them some credit. If they cannot do their job then it is time to train them and give them a second opportunity. If they still cannot do their job after training then it is time for them to get out of IT. I hear Obama is asking for volunteers to work in the community.

Can't Base Everything On...

I have been following Gartner and Forrester's research content on SOA, EA and other IT concepts from 2005 till present and I have learnt the following:

• Do not base ALL your IT decisions on Gartner and Forrester's predictions and recommendations. I have seen large IT companies make investments in technologies and products where the investments have not panned out because their IT environments are quite different. For instance SOA was the hype in 2005 however current Gartner analysts are saying that SOA simply doesn't work well in most IT environments. Research analysts tend to do that alot since they are reacting and analyzing current trends and make predictions and later contradict their predictions.
  
• Scope Best Practices and Products using Research. Rather than testing ten separate products for your certain IT requirements, you can choose the top five products as assessed by Research companies like Gartner and Forrester. Do assessments on the top five products and see how well they meet your IT requirements and how well do they perform in your IT environment.
• Use Research for Initial Business Justification. If you are looking to address a business problem and you want to follow Gartner or Forrester's recommendations then use their material to carefully craft a business justification on why you want to prototype their recommendation. Please keep in mind that you should address Return on Investment even if the recommendations don't work for IT enviroment.
• Engage these Research Companies. You want to market your IT strategy and progress then I highly recommend that you keep a lively engagement with the Research analysts where they will refine their research using your enviroment's results and at the same time they will give insight into current best practices. But be careful not to waste their time or yours by not having a detailed strategy on how you want to execute your vision and how you want to collaborate and market with these Research companies.
• MOST IMPORTANT: Consider the Research material however stick to your vision and requirements in executing your vision. Afterall you know the 50K feet view and the 1 inche view and therefore it is your responsiblity to execute it.

Good luck!

Actionable Enterprise Architecture

We, at work, are trying to define what is Actionable or Usable Enterprise Architecture (EA). As many of you that EA is a capability that almost every Chief Information Officer (CIO) has in his Information Technology (IT) Department. The exact definition of what EA means is different for every IT shop. Now trying to create an EA which delivers business value to an IT Department and to the overall business is as elusive as finding Weapons of Mass Destruction (WMD) in Iraq. Actionable EA is not easy. Folks at US Government agencies think EA is a capability to add OMB Exhibit requirements. This makes things a bit harder. Anyway here are some tips to make EA successful in your IT department:

1. What is the organization trying to achieve by having a EA capability? Each organization has different expectations for EA capability.
   
2. Know your stakeholders and understand EA requirements: Identify the stakeholders in your organization who will benefit from the EA capability and then get to know them and understand their EA requirements. This way you are also marketing your program and capabilities.
3. Have a Starting Point: Most EA folks say having a good EA framework like TOGAF or DODAF is a must since it helps you identify the various components of your IT Department and then you can use the framework as a gauge to see how IT Department is maturing and progress. If you don't have a framework or don't want to use one then identify various components in the IT Department, model them, access maturity and bimportance of each component within the IT Department
4. Take It Easy - Don't propose strategies where whole IT Department is documented with extra fine granularity and various tiers (data, infrastructure, application, business, etc., etc.) of the enterprise are concurrently trying to improve their tier. Atleast initially, you should address a set of systems, see how your strategies are being implemented and then refine them for the next iteration.
5. Market, Market and Market some more - Tactical functions within an IT Department like Help Desk support, Data Center services won't understand the long term benefits of EA. It is therefore beneficial to publish a EA website or a knowledge management site like Wiki. This allows people to understand what EA means to their IT department and we can level set their expectations.
6. Problem Solving: - Show me an IT Department without problems and I will show how Pigs can fly! Every IT Department has problems related to policy, process, systems, resources, etc., etc. It is our job to show them how EA can solve their problems.
   

President 2.0

I believe our President has done it. President Obama is using technology to its fullest to , do his job. He is pushing his agenda through his websites, grass roots campaigns, twittering pages, YouTube videos and many others. In fact I writing a blog about his use of technology, is an accomplishment. Currently he is pushing Health care agenda and I, personally, am skeptical about it but I admire about him is that he is pushing critical issues to the masses using web technologies. True, a regular Joe won't be able to vote a "Nay" or a "Yeah" in the Senate or the House but at least I am aware of the issue and I can start a grass roots campaign for it or against it. I can also use technology to push my voice using Blogs, social networks and other Web 2.0 enable medium. I have admired how Obama has used the Web to rally the people to campaign for him. I signed up on his site when he was running because I was curious and I wanted to see what he is all about. I read up on the issues on his site and McCain's which helped me make a decision on my vote. I also got an opportunity, which I took, to volunteer at the Presidential Inauguration. It was a great experience and I wouldn't have been able to experience it if Obama wasn't reaching out to the masses via the web. Anyway he is revolutionizing on how campaigns are done because his usage of technology. I wonder when President 3.0 will come. Stay Tuned.

Here is a video of Obama's healthcare from PBS which includes my friend Jonathan's wife Zaneb Beams. Even if you hate Obama, you have to appreciate how he used Web 2.0 technologies.

Twitter-mania!

As everything has a "buzz" lifespan, Twitter seems to be growing and various entities like my former employer, ManTech International and others, have started Twittering. I have been twittering for a few months and I have seen that it is a great way of creating organic social groups or Communities of Interest (CoI). For example I tweeted about "Groovy on Grails" and next thing I know, I am being followed by Grails evangelists. I have had web designers requesting me to let them follow me since I tweeted about Photoshop and other Adobe products. It is a neat thing that people are following micro-blogs since people don't have time to read large blog articles. I have discovered that with Twitter that you can create a buzz about yourself or about some of the actions you do. I have seen people Twitter about their skills to market themselves. I have seen entities like CNN Breaking News which tweets the latest stories in news. I follow Pete Carroll who markets USC and how cool it is be a USC Trojan. I also follow Shaq and Mark Sanchez, Jets QB draftee from USC and many more. The question is why I do enjoy following them and other one million plus who follow Ashton Kusher. The answer is that it gives a person insight into celebrities. A way for us to relate to them. They are human like us. For example, Mark Sanchez loves hamburgers and he is always tweeting about Hamburger joints in NYC or his practices at the NY Jets facility. I, personally, like following people I know since it gives me a better insight into their lives.

Now I ask the question, "Does it make sense to have companies like ManTech International Twittering?" I answer that asking another question, "What are they trying to achieve?" Is it recruiting tool, employee retention tool, or a way to generating more buzz? I suggest that they should first monitor who is following them? Is it ex-employees like me or is it current employees or someone totally different? As an ex-employee, I would be interested if they had any interesting positions open up. If I were a current employee then I would like to hear about new benefits or about some new business and potential career development. If I were an outsider, I could be a competing business, a potential stock buyer, a prospective employee or a prospective client. The question is what are companies trying to twitter? There is a market there but some creative analysis and speculation may increase a company's image, moral and the quality of the work force. As for me, I wish Twitter had a better UI.

Consultant - The Human Tool

As a US Government employee, I am constantly bombarded by contractors wanting to provide their services and vendors who are constantly selling me their Custom-Of-The-Self (COTS) products. Therefore as a US Government employee, it is my duty to determine if I need consultants and COTS products for some of my organization's strategic activities. As a goverment employee, my primary responsibility is to accomplish my organization's strategic and/or tactical objectives while managing to be diligent stewards of US Tax dollars. Anyway here are some thoughts regarding consultants:

• Don't let the consultants drive the strategy for your projects - The consultants try to couple themselves to your organization processes and try to you dependent on their services.
• Be up front - Tell the consultants what your expectations are of him and how his performance will be monitored and assessed.
• Monitor their perfomance - Hold them accountantable to the project schedule and demand deliverables to be met on time.
• Take ownership of the Spend Plan - Don't let the consultants manage the spend plan for you. This is a big no, no. Take ownership and decide how you want to mange it.
  
• Define and demand deliverables - Define the deliverables and when they should be delivered to you. Keep them accountable for the deliverables.
  
• Consultant Scope Creep - I call this when consultants are working with you to know your domain and they might try to expand the scope the deliverables and push the date back. This is not a good idea.
• Believe in a Reward system where consultants can be retained because their project were successful or show them how they can retained with their good work.

In the end, consultants are nothing more they glorified Enterprise Architecture Tools. The consultants will do what they are told to do within the context of the agency. Having good requirements on sort of consultants should be done by interviewers and sharp managers would thinking about their potential reuse after this project. The only problem with the consultants is they don't have a new version available. :)

IT Role Players

Today I had a conversation with someone about the difference between an analyst and an architect. This blog entry comes out of this discussion where I share my opinion about various Information Technology (IT) roles.

• Analyst - Someone who spends time analyzing, decomposing the subject matter and sometimes provides the best option depending on the requirements. This person is not involved in coming up with a noveau solution but rather is involved in doing detailed analysis. There are requirements analysts, business analysts, process analysts, chain-management analysts, financial analysts, technical analysts, security analysts, program analysts, etc. etc.
• Architect - This role is a confusing one. I have heard that it is every developer's goal to be an architect or this person is nothing more than a technically savvy project manager. I have also heard that an architect is nothing more than a glorified analyst. After doing Architecture for eighteen months, I have to say it is a hard job. (Don't get me wrong. Analysts also have a hard job since they have to extract their analysis from information which is explicit and implicit). Architects take the analysis from the analysts and synthesize a solution for the problem. The architects have to consider the tactical constraints and its alignment with strategic goals. This person has to constantly ask himself, "Does my proposed architecture satisfy the customer needs, align with the strategic roadmap, meet the project deadlines and can it be implementable with the current resources (i.e. resources, infrastructure, standards)." There are enterprise architects, application architects, software architects, solutions architects, infrastructure architects, services architects, data architects
  
• Standards Person - This person usually work in a Technical or Functional Group defining standards for a particular domain. He or she needs to have good analysis skills, architecture skills and most importantly have excellent written and oral communication skills. This person needs to level expectations with the organizations they represent in the Standards groups and at the same try to push their organizations requirements into the standards specifications. They have a hard job of strategically aligning the standards, (they are working on) and their working bodies goals and with the organization's goals. Word smithing skills should help. There are standards people are involved in technical standards, and process standards like Software Development Lifecycle (SDLC) and Configuration and Change Management processes.
• Engineer - This person is a problem solver and he is usually involved in the "weeds". Usually the architecture aligns strategically with the organization's goals, meets all high level requirements and meets all other constraints. However this person addresses the finer problems within the overall architecture and solutions that maybe temporary fixes or configuration changes. For example there exists a mission critical system which was architected perfectly however the user base has increased eighty five percent and currently the system is experiencing a significant lag time which is affecting a business process. The next release is in six months. This is where the Engineer steps in. He determines the problem, designs a solutions and implements it. He documents the problem, design and implementation for the architects in the next release. Voila! The engineer has saved the day again. There are software engineers, systems engineers, process engineers, test engineers, etc, etc.,
  
• Developer - This person takes the high level architecture, designs the low level design and then implements it. If the architecture doesn't address the details because the architect doesn't have the time to design low level specifications or if the architect is not familiar with the technology then he or she can leave it to the developer. There are usually software developers.
• Programmer - If the architecture is extremely detailed and granular then the programmer has to implement the design. This is done where systems are designed to interfaces.
• Administrator - This person usually administrates an IT function. A system administrator administrates the system by maintaining and optimizing it within the constraints defined by the architect and the engineers. There are system administrators, project administrators, program and organizaton adminstrators.
  
• Project Manager - This person is responsible for managing and delivering a project which has beginning and end states defined. This person has resources to manage and is responsible for the appropriate deliverables to be completed within the project timeline. This person is not strategic but his or her main objective is to meet the end state with the project constraints.
• Program Manager - This person is responsible for managing a program which inconsists of on-going projects, projects to be executed and projects that were completed. This person is strategic since he or she need to program goals however they meet their strategic goals via projects which are tactical in nature. These people are comfortable dealing with project managers and their projects.

Please let me know what you think. These are my thoughts and I haven't spent any time validating if my definitions meet PMBOK or PMI standards.

Work vs Tweet

Enterprise Tweeting anyone? I don't think so. Twitter is great for promoting yourself virally however I don't see any point of "tweeting" when you are at work. This capability exists with the various enterprise Instant Messengers like MSN Chat or Lotus Notes client however I see people hardly using it. The only time I really check someone's status is if they are available for a meeting or not. This status is available via the Calendar sharing capability available on Outlook, Google Calendar, Lotus Notes, etc., etc. So in this brief entry, I conclude that I don't see any Tweeting in the workspace. Who wants to Tweet when they have to work? ;)

Software Language Roadmap

As many of you heard that Oracle is the process of purchasing Sun Microsystems (Sun) and many techies like myself are weary on what will ever happen to current IT standard technologies like Solaris OS, SPARC workstations, MySQL relational databases and most important to the Java Software language. Sun did a good job of maintaining the Java language which inturn has matured and is currently quite popular in the development community. I have to give kuddos to Sun where the language matured from a bulky and clunky language with Enterprise Java Beans (EJBs) to a more streamlined software language which has be refined to a fine consistency. I, however, think that the Java has reached its pinnacle and now it will slowly fade in the mist where other legacy buddies like COBOL, FORTRAN, PASCAL, LISP, etc, etc are waiting for it.

If you are a Chief Technology Officier (CTO) of any mid to large size enterprise, it is time to ask your planners to hash out a Software Language Roadmap which should address the following:

• What sorts of languages will peak in the next 2 years, 5 years and possible 10 years?
• What sorts of infrastructure will be needed to maintain applications with these languages?
• What will the cost of development of these applications?
• Will it impact current applications?

Enabling the IT component of business with Service Oriented Architecture (SOA) was promising since it offered a closer alignment to business processes, and the wonderful level of flexibility. Unfortunately flexibility brings numerous levels of abstraction and system integrators working with process analysts to develop these flexible services. During the enabling process, enterprises have realized that there is a cost associated to the degree of flexibility. Is flexibility worth the price? Next came the promise of Web 2.0! Web 1.0 allowed users to discover information using Web. Web 2.0 allows users to discover information and aggregate information for their personal uses. It also allowed users to disseminate their perspectives on the information (kinda like this blog). Enterprises see the promise however they are leary in giving their users the power to disseminate information with their perspectives across their networks. Currently businesses regulate their users on when and where they can blog if the users are allowed to blog. Currently the most promising thing Web 2.0 component in the business community is the Wiki. Wikis are usually viewed as organic knowledge bases which are maintained by the users. I personally don't see Blogs and Social Networks (sorry ASpace!) won't take off in an enterprise. So back to the drawing board and we need to ask ourselves, "What next?" As a developer and as an architect, I believe application development will be done in scripting languages like Ruby and Grails. They follow the concept that it takes alot less time to modify a baselined application then to build one from scratch. These languages also imply that these baselined applications have the right architectural foundations like built with design patterns, and loose coupling. They are script based language which allows developers to save alot time by skipping on the compile step. They also provide unit-testing capabilities. I have worked with Groovy on Grails quite a bit and I really like it. I am still learning Ruby. I also see close source companies like Microsoft and Adobe following this paradigm in their new ActionScript or .net specs. Every executive asks about security vulnerabilities with these languages and security is addressed as these languages mature. I wouldn't ask my developers to build my business applications in Groovy on Grails or on Ruby on Rails yet since they are still new but I would start drafting my java exit strategies. Don't let your enterprise get lost but plan your roadmap and stick to it.

Different way of programming

For the last week or so, I have been developing a dashboard for an Enterprise Architecture (EA) at the Federal Aviation Administration (FAA). Due to various organizational constraints and confusion regarding where should the EA repository should exist, associated user access issues and which tool should render the dashboard; I am developing the dashboard using ExtJS AJAX framework. Six months ago, I would have spent a few days trying to understand the Application Programming Interface (API) and then slowly build the application scratch. After working with Groovy on Grails and Ruby on Rails, I decided to take the approach of customizing an example, which is provided in the ExtJs framework. This approach has saved me alot of time and I have a better understanding on how ExtJS works. I admit that I don't have a detailed understanding on how ExtJS is designed and how it should work; but I do know enough to say that I can build the User Interface using ExtJS. So if you are getting ready to code in ExtJS then I say to you, "Ext.onReady(..."

So in closing, I would say that it is faster to customize existing code rather building it from scratch. I have been enjoying working with this JavaScript framework.

What is a Service?

To understand Services Oriented Architecture (SOA), we must understand what a Service is. In the world of buzz word confusion, the notion of SOA is misunderstood which in-turn hurts the Information Technology (IT) component a business which in-turn hurts the business itself.

Therefore the components of any Service (business service, web service, project management service, aviation service or security service, etc., and etc.) should be identified and modeled. All Services contain the following:

• Inputs
• Outputs
• An Interface which facilitate the inputs and outputs
• Cost associate in conceiving, designing, implementing and maintaining this service.

Here are also some characteristics of any Service?

• How is the Service invoked? – Service Invocation
• How is the Service delivered? – Service Delivery
• How good is the Service? - Quality of Service
• How is the Service supported – Service Support

Even though all Services have the common components and characteristics, it is important to understand that Services are realized within a context and some characteristics or attributes become mandatory. For example within the context of technical solutions architecture, Services can be realized as Web Services, Database Services, or any other Technical Service. Technical Services usually have well defined Inputs, Outputs, Service Interfaces and the Service Cost which is usually associated with the licensing of the technical infrastructure or the cost of building the technical capability. For example, the term “network protocol” is big within this context since it describes the underlying architecture of the Service Delivery mechanism.

If the context is a Business Automation process, then Business Automation Service usually involve the application of Technical Services to address how a certain business process or a sub-process is automated. Since the application of Technical Services and Technical Services may sound similar, they are uniquely different. The lack of clear delineation of what a Business Automation Service is and what a Technical Service is one of the common underlying problems within SOA. There are also Services within the context of a Business. For instance, Oracle Corporation sells Support Services for its products. The Support Services usually include Help Desk personnel who answer and guide Oracle Support Services’ Consumers on how to resolve issues with the Oracle product. Oracle and others have tired to automate this component in the Support Services model however the “human touch” and human interaction is highly desired in the Support Services Consumers’ community. The Support Services Consumer invokes the service when he or she is having issues with the Oracle product, which has Support Services attached to it. The Service Consumer uses the phone or website interaction as his or her interface with the Oracle Support Services. The Service Consumer doesn’t need to know who the other person is, how is he getting paid, what are the Support Services’ processes are, etc., etc. Now the question I often ponder about is:
“Can a business be truly SOA with respect to various contexts and not just IT?”

I believe it can be done however will the Return On Investment worth this change.

Driving a Ferrari and getting Screwy with Groovy!!!

For the last few days, I have been trying to clean up and write new functionality for an existing e-commerce web site which has been written in Groovy on Grails. When I first played with Groovy on Grails, I was amazed at the simplicity at how straight forward web application are amazed. It like getting into a Ferrari, starting the ignition, release the hand brake, hit the gas pedal and let it fly. As you are driving the Ferrari, you realize that you don't know how to turn the Ferrari at 120 mph or do a donut in the snow in it. You then slow down the car and slowly get to know the car. You appreciate the contours of the car, the neat blue tooth capability and the simple ease on how the car handles. As you are appreciating and getting to know the Ferrari, you realize that you are loosing time and wonder if it is really worth it. In the end, mastering on how to drive the Ferrari is your greatest asset as far as going to new destinations.
You must be wondering how is Groovy on Grails and an expensive Ferrari are connected. The answer is that they are connected. To fully appreciate the neat features of Groovy on Grails, you have to sit with the language and get to know it over via your handy dandy IDE. Groovy on Grails may sound wonderful in the beginning however you realize that it is not that easy when you want to build custom functionality. I struggled with building form validation for fields which appear on web form but the data in these fields is not reflected in the database. Groovy on Grails may be a great language however it is like the dark ages in terms of documentation.
Anyway I figured all of my issues for this release and I also found a bug in the Groovy on Grails and a quick work around:

1. I have a UserAccount class which looks like this:

   
   class UserAccount implemments Serializable {
   
   String username
   String firstName
   Address address = new Address()
   
   static def constraints = {
   
   }
   }

2. I have a Address class which looks like this:

   
   class Address implements Serializable {
   static belongs =[user:UserAccount]
   
   String streetAddress
   String city
   
   static def constraints = {
   
   }
   
   }

3. I have a gsp file
   

I noticed that the textboxes for streetAddress and city didn't highlight in red when the textboxes had invalid data. To get around this issue, I wrote a simple JavaScript function which manually highlighted the textbox if the error message for the textbox is generated. This how ever didn't work (this is the bug). Here is what I had for highlighting the city textbox:

${hasErrors(bean: person?.address, field: 'city', 'errors')}'

This didn't work on its own and the Javascript didn't work. After spending some time with this bug, here is how I resolved:

${hasErrors(bean: person, field: 'city', 'errors')}'

This made the JavaScript to work properly. Hope it helps

Can SOA be achieved in an enterprise

For the last year or so, I have been working for the Federal Aviation Administration (FAA) as a Services Oriented Architecture (SOA) Subject Matter Expert (SME). It has been a challenge to see how various folks view SOA the panacea for IT related systems or enterprises. Each stakeholder within an organization has different definition with respect to SOA. So far I have noticed the following at the FAA, we have:

1. Data Services - Services that carry data
2. Business Services - Services that meet a business need
3. ITIL Services - Services which meet Help Desk and Operations centric services
4. Business Process Services - Services which emulate business processes and they use standards like BPEL and BPMN
   
5. Web Services - Information is exchanged over the HTTP protocol in XML or as attachments which are in SOAP container
   
6. Java Services - Java enabled services
7. RESTful Services - Information is exchanged over the HTTP protocol in XML but the information is not in a SOAP container.
8. Orchesterated Services - Services which are made of services
9. etc., etc

As you can see, Services can be confusing. To add to the confusion, we have other tools and methodologies which make SOA a zoo. We also have people who view SOA serving different purposes. In the end, they are all true since they are identifying components which can be or may be true in an enterprise. Here is my take on SOA. SOA should be viewed from a Enterprise Architecture (EA). EA identifies (if it is done right) the "As-Is" state of the IT enterprise and proposes the "To-Be" state of the IT enterprise.

EA should also have a strategy on how to achieve "To-Be" state in a timeframe. This is usually articulated in various EA artifacts like Roadmaps, line of sight documents, strategy documents and an EA repository. Other components that need to implemented to give a true EA picture is to have an enforced System Development Lifecycle (SDLC), Change Control Board (CCB), and Configuration/Change Management (CM). The other thing is that to have a working EA, all of the stakeholders must buy into it. I am a big fan of The Open Group Architecture Framework (TOGAF).

Back to SOA now, if EA recommends that SOA is one of the possible approaches to meet "To-Be" state then it needs to bought by all stakeholders in the enterprise. The following steps need to be done when an enterprise wants to use SOA to achieve its goals:

1. Define a Service Data Dictionary - This will reduce the confusions when talking about services.
2. See if the EA strategies identify any systems which need to be consolidated or broken-up.
3. If so then use SOA in system(s) migration
4. If all new systems are built in a SOA fashion then address SOA governance
   
5. Address SOA governance by designing and implementing processes and groups which deal with SOA governance.
6. All new SOA services should be projectized
7. All new SOA services should have a Mission and Vision statement
8. and on, on

In the end, will SOA ever be truly achieved in the FAA. The answer is "No"! However pursuing SOA will help FAA identify gaps in its enterprise with respect to its EA since it forces various stakeholders to communicate together and address how some of the internal processes should be achieved. This is a big key for any successful IT enterprise. Adopting SOA will not provide a successful EA without having a working SDLC and appropriate mechanisms which provide accountability.