Oh Yeah!!! I mean OUYA!!!

Tech blogs and sites are talking about OUYA. OUYA is not a gaming console for the Kindle Fire or the Droid Razr but rather for the “old school” screen, the television. My research shows that OUYA is composed of a slick cube shaped console and a controller.  

OUYA's application programming interface (API) and its documentation, which are accessible via the OUYA website, show that the API clean and lightweight. The system is written on the Google’s Android OS which is written in Java. The OUYA API consists of six Java classes and it looks like the developers will have to develop interfaces on how they want the OUYA console to interface with their games. It’s a smart approach. The responsibility on how a game should interface with the OUYA is on the developers and not on the OUYA staff.

What does this mean for the gaming companies? The companies like ZYNGA and EA will need to have resources who will code the OUYA functionality for all of their games. The companies would also need to host their games. Can we repeat the words, “CLOUD COMPUTING” (again).  

What does the OUYA platform mean for customers? This approach is truly disruptive. This opens up the platform for traditional Java developers like me which in turn means more games will be developed.  

What does the OUYA platform mean for the business world? Businesses can now buy services where specific games can be built for their business needs. Game based learning is rapidly evolving into the main stream business. For instance the Federal Aviation Administration (FAA) is currently exploring games to train the next generation of Air Traffic Controllers. With a platform like OUYA, FAA can develop games a lot less cost since Java developers are not that expensive and publish these games to train new Air Traffic Controllers or even get a high school age person interested in managing air traffic.  

Even though the possibilities of OUYA are great, I worry about the security threats with a platform like OUYA. OUYA security access controls are based on its open source Android operating system (OS) and stores like Google Play don’t test the games for malicious code. Unless this policy has recently changed, OUYA may not be adopted by large organizations. If OUYA can provide a secure app store, OUYA’s potential is quite high otherwise it’s to be determined (TBD).  

In closing I will know that OUYA is successful when Stuart Scott to say “OUYA” rather than “Boo Yah” on ESPN SportsCenter.  Here is also a video I found on the OUYA website.

Buddy it ain't dream computing. It's reality!

A few days ago, I had an interesting conversation with my co-worker Bill about modeling to a specific project or program or should we model with the enterprise in mind.  I then asked the question.  Does it make sense to model data, business processes, or an software modules like the federate query for the enterprise?  The answer is No!  This is because the enterprise is an ambiguous area.  Nothing is clearly defined however every business and every person recognizes that there is a bigger universe than their specific project and program.  IT personnel will throw everything in the enterprise bucket if it is ambiguous, idealist or flat out dreamy. Architecting for the enterprise without requirements, constraints, road maps or even goals is what I call dream computing.  It is only possible in dreams.    If you want to argue with me or just disagree, I suggest that you hit the pillow and just dream about your reality.  Frankly in my reality, everything is driven by financial figures and what makes business sense.

So getting back to the discussion with Bill, if your organization wants to push enterprise level thinking, modeling, design and development capabilities at the enterprise level then your organization should have a strategy.  You can then validate the strategy by picking an architectural framework which meets the organization requirements.  The strategy should also be defined by the organization requirements.  The organization requirements can captured as quarterly goals and have an  idea how they want to achieve the goals.

After you pick the framework then you need to decompose the framework to understand how you can use it to meet your organization's requirements.  For example Department of Homeland Security  (DHS), Federal Aviation Administration (FAA), and other US government agencies use the Federal Enterprise Architecture Framework (FEAF).  The FEAF was developed by Office of Management and Budget(OMB) and it meets their requirements.  Unfortunately agencies like the DHS and FAA use FEAF to do data calls and develop roadmaps (40K foot view is an understatement).  This however leads to major heart burn among the agency's management community see FEAF doesn't meet any of their requirements.  The management community subscribes to Gartner and Forrester and these publications which state that EA is better than sliced bread (okay I am overusing the"sliced bread" phrase).  The management community then wonders why is our EA team so horrible.  They pester us with data calls and develop academic road maps using FEAF and they have no value to the agency.  This blog can go back about talking about the importance of communications from a EA program however I have blogged about this issue enough for the last couple of years now.  I am now going to talk about the individual agencies failing to develop a EA program with their ability to capture oranizational requirements.   If your government agency's EA program is done well then the data calls to OMB  should be a cinch. Usually EA programs complain about that they don't have any sponsorship.  In highly bureaucratic organization where you have to pick your battles, would you give sponsorship to an OMB centric program.  I don't think so.  This is also because the organization in general has not done its due diligence in defining their strategy.  The government agencies wait for answers from the top and are extremely reactionary.

Back to Bill's conversation.  I told him that you cannot  do anything in the Enterprise without requirements.  You can model the enterprise to n-level granularity or the n-level sub processes.  In the end it is a wasted exercise because businesses are not going to pay how many rodents get stuck in a plane. If management is forcing you to go the enterprise level then identify the framework and work with the approach I proposed.
Where is my pillow again?  I need to dream about new blog entry ideas.

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.
   

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.

EA is doomed to fail!

Enterprise Architecture(EA) in any organization is bound to fail because it doesn't do a good job of capturing the true state of an enterprise. When people talk about EA then they talk about systems, applications, and assets within the enterprise however organization structure, an understanding of the business itself and its processes are not captured properly.

Anyway that is a quick rant!!!

Zapped

Last week, I was in a ZapThink Service Oriented Architecture (SOA) Bootcamp. It was a descent class since they derive their material from actual SOA implementations in large corporations. They presented high level principals and "gotchas" but I felt it lacked something but I cannot tell what. I thought the ITIL v3 Foundations course was more intense and it actually presented some excellent concepts. I highly recommend taking ITIL v3 Foundations course and the ZapThink bootcamp does a good job of re-enforcing overall same concepts which are:

• How does IT solve a business problem? This is key since vendors and developers tend to buy the tool or solution and then retrofit it to a business problem. I have been involved in couple of projects which spelled D-O-O-M-E-D after they were cancelled.
• Capture Business Processes - This is an other key since requirements are derived by analysts which inturn are passed down to the architects and engineers. Architects and Engineers design solutions to the requirements. If they had an insight into the business processes, the solutions could be better and cheaper.
• Business Agility - Flexible IT systems provide businesses more flexibility to be agile. Services support this paradigm however defined Configuration Management processes are key as well.
• Architecture - Enteprise, Data, Process, and Technical Architectures are key since they provide a defined approach in designing a system or an enterprise. No more Ad-hoc development projects. As a developer and an as an architect, this is key since developers love to know their constraints. We, as developers, have been burnt by poorly written code or no documentation.

Overall good IT architecture with SOA or no SOA, involves alot of common sense, a business understanding and knowing your constraints. Ideas are great but we all have to be realistic.

IT Architecture = Communications

For the last six months or so, I have been working for the US Government as a Services Oriented Architecture (SOA) Technical Lead. Eventhough that is my functional title, I act more as a Information Technology (IT) architect. It is my first job where I am an IT architect. At my previous job I was a part-time XML data architect where I did alot of data modeling, data analysis and then defend why I modeled certain data structures a certain way. When I was not a XML data architect, I was a JEE developer. Eventhough developers aspire to be an architect because they can get to design the systems and leave the grunt work to other developers, this may not be true when the developer becomes an architect.

Couple of summers ago, I took a class to become a Java Enterprise Architect and it is there I learnt that an architect doesn't have a set role. As a developer or a project manager, your roles are pretty much defined but an architect's role is ambigous. In the class, I was taught that one of primary responsibilities of an architect is to see his system or project succeed. In some projects, he can be coding and developing reference architectures and in other projects, he is basically working with the project manager in refining requirements. After being an IT architect for the last six months, I have to say that the instructor was absolutely correct. An architect's role is ambigious to a project but every project must have an architect. An architect is a rare breed because:

1. he understands what is being built and why it is being built
   
2. he can look at code and have code level discussions about the software code.
3. he understands the business problem and why the system is a value to the customer
4. he can work with business analysts in refining requirements or make them more abstract which might give the development team more flexibility
5. he can sit with the project manager and hash out a realistic Work Breakdown Structure (WBS)
6. he can recommend modifications to the project scope if the project is running behind schedule
7. he doesn't need to be the best programmer in the team
8. he doesn't need to design the system but rather review them
9. he doesn't need to write a test plan but he can evaluate it
10. he doesn't need to be a guy. Women can be architects too.

And the biggest trait an architect should have is that he or she should be able to

COMMUNICATE

with various stakeholders and he or she should be able to discuss the system in technical, non-technical, and business terms. Architects should be willing to exchange ideas with other architects and they should humble enough to accepts mistakes if they made them.

The role of an IT architecture will expand as more businesses go into collaborative modes of information exchange since they need to be aware of standards and they should understand the newer technologies. So for all aspiring programmers in the world, it's time to shelf the pocket protector, clean the stacks of burnt or blank CDs, get a haircut, stop living on Red Bull and be more social. Try to interact with your teams and peers since a great idea is bad idea if you cannot communicate it and a better idea is to have your good idea validated with others.

Can EA ever work?

A few months ago, I was sitting with my supervisor, who is an Enterprise Architect (eArchitect), and Gartner consultants discussing on how to sell the concept of Enterprise Architecture (EA) to our organization's senior management and how to create a successful EA in our enterprise.

Before we talk about whether EA can work, lets define the term Enterprise Architecture.

the description of the current and/or future structure and behavior of an organization's processes, information systems, personnel and organizational sub-units, aligned with the organization's core goals and strategic direction

- Wikipedia

To capture the true essence of EA, Microsoft.com states the following about EA: "For the first time there is a methodology to encompass all of the various IT aspects and processes into a single practice.

Processes
As you can see, capturing every process and nuance in an enterprise is a daunting task. An enterprise can have mature documented processes which are known and recognized by the enterprise's resources. These processes are easy to document. There are other processes which are well known but no one has documented. There are also processes which exist but they are known by the select few. And lastly there are processes that no one is aware of but they do exist.

Resources
So who do you work for? What do you do? What projects are you working? What is your skillset? These are the typical questions an eArchitect has when he is tackling the resource view in the overall EA. The questions might be simple ones to answer however they are quite hard to ask. eArchitects don't want to invade in someone's space however they need to collect the information to complete their model and render different views of the EA to their management folks. It would be alot easier if the eArchitects went to the Enterprise's Human Resources (HR) Manager. The HR Manager might even be cooperative to share his or her information however their information might not tell the actual picture. For example, my official title in the enterprise I work for is "Computer Specialist" but my functional title is "SOA Technical Lead". Our Enterprise's HR Manager does not capture our functional titles. Therefore just going to the HR Manager and getting information from them does not give the real picture. There needs to be actual discussions between the EA team and low level managers.

Assets
What operating system is running on your operating system? Do we have licenses for this software? How come we have four versions of Microsoft Word? As you can see, assets are a big deal in an EA. Capturing assets in an EA is important since it shows an enterprise view on what, where and how did the enterprise obtain these assets. This information may be great for asset inventories however eArchitects need to make data calls with various groups to capture this information. Without understanding an enterprise's business processes, eArchitects will not be able to infer why certain assets are higher than others.

Application
eArchitects have to spend time with enterprise applications to determine if the applications are meeting some critical requirements in the enterprise. eArchitects have to work with application Subject Matter Experts (SME)s to obtain this information. (Once again eArchitects are doing a data call)

As you can see for a successful EA, eArchitects have to capture lots of information and then synthesize the information. This becomes extremely hard when other groups don't see immediate rewards in sharing their group's information. If there is no information, there is no EA and when there is no EA then the enterprise cannot be improved. For organizations to get a better view of their enterprise, they need to mandate their internal groups to share their information. If the internal groups don't share their information then the consequences are, frankly speaking, dire.

In summary, EA can work however EA will not work with extremely bright and talented eArchitects, buying the state of the art EA software nor simply creating numerous EA models. EA will work if the upper management take time and creates policy which will give power to the EA teams to capture their organizations critical information. The upper management should also investigate ways on how to automatically capture some of the EA information in their processes.