Enterprise Software Development – Introduction

Information technology (IT) is part of most enterprises today. And that is exactly where IT stops: as part of the enterprise. The enterprise has its own vision, mission, plans and governance as affected by many factors not exclusively related to IT. In fact, IT is just one of the many players contributing to the enterprise’s ecosystem.

For most companies, IT is not the center of their businesses, although IT can inspire and motivate innovations of new business areas; improve operations and, at the same time, help to reduce costs; or provide the tools to enhance decision making in order to give the enterprise its competitive edge in the market or in the industry it belongs to. IT is a service and the IT organization simply serves it.

The enterprise is in control of its IT and never the other way around. IT Governance and, its key component, Enterprise Architecture in computing are important knowledge in making sure that the enterprise is in control of its IT organization. Accordingly, the enterprise must establish the IT organization with respect to its potential evolution and advancement. There should be a balance by which the ecosystem allows for growth. This balance should, therefore, be part of the principles in creating the enterprise’s IT roadmap.

The enterprise’s IT roadmap helps shape the management and style of software development. Waterfall or agile? Compact or distributed? Components or services? These are some of the questions that may be raised as the IT organization matures. Regardless, what matters is that the IT organization’s software development team is aligning their efforts to the plans of the business.

Software development for the enterprise is different from simply developing software products. Enterprise software development aims to deliver software products with the enterprise in mind. It should serve the current and future needs of the business. The readiness of software to survive the future is critical to its overall success. This challenge, on its own, is very difficult as it requires business knowledge, involvement and foresight from the software development team itself.

The ability of the software development team to plan its structure and processes is crucial. How it asseses itself and its growth affects the direction it takes in all aspects. There are pit falls to watch out for. There are pros and cons to consider. Still, what is important is that the team recognizes that it is existing and working for the enterprise — no more, no less.

The disciplines, principles, strategies, science, approaches and techniques to be followed by the software development team define itself in the enterprise. In reality, the simplicity and the complexity of all these depends on the capacity of the enterprise to support them. There are cases when the software development team should compromise for the sake of the enterprise. This is natural and should be highly considered and factored in to ensure success.

Enterprise software development is generally easy. Compared to Microsoft’s business to create generic software products to target various industries and enterprises around the world, enterprise software development focuses on a much more controllable audience. Although, this fact does not limit the IT organization to plan itself beyond the designs of the enterprise, the IT organization is, first and foremost, expected to prioritize the enterprise as its base customer. In line with the IT organization serving IT services to the enterprise, enterprise software development should, likewise, be a service to deliver software for the enterprise.


TV vs. “Internet TV”

Bill Gates is excited in this article where he says the future of the TV is in the Internet. I have nothing against his vision from happening. It might, yes, but perhaps, not in 5 years.
First and foremost, TVs are not affected by the number of users concurrently using it as opposed to the Internet’s performance degradation when bandwidth traffic is heavy. Next, for as long as TV broadcasting towers are not damaged, TVs are not affected by earthquakes. TVs are, also, not attacked by viruses, threats and hacks as associated to computers hooked on to the Internet. Lastly, and perhaps the most important, TVs can be accessible without additional connection costs as shows can be broadcasted by TV networks that enables content to be delivered to the masses with only one simple requirement: for the viewer to own a TV set — now, compare that to getting a computer, monitor, keyboard, mouse, modem, phone line, ISP subscription, software, etc. to access an "Internet TV".
Please don’t get me wrong. I do not think that Bill Gates’ vision will never happen. I think it will, yes, but the transition might take longer than 5 years — even if Microsoft, this year, pushes for Windows Vista (with built-in Media Center) and the XBox as the ultimate TV products of the future.

ASP.Net AJAX is Out!

Ok, so I’m late with the announcement. But it’s out! Formerly called Atlas, ASP.Net AJAX is now officially version 1.0. Toolkits and other related products are available as well from the ASP.Net AJAX site. There are also demos available.
AJAX (Asynchronous Javascript and XML) was a name coined by Jesse James Garrett in February 2005. It is basically made up of many old but disparate techniques in using the various web client technologies together (such as HTML, DHTML, CSS, Javascript and XML) in order to create rich online user experiences. The technologies themselves and the techniques were not new. But when they were given their own name, it became something important enough to inspire and motivate the development of the many AJAX frameworks. Read more about the history of AJAX from Wikpedia.org.
Microsoft’s ASP.Net AJAX is one of the many free AJAX frameworks already out in the market. It is designed to work well with Visual Studio 2005 and later. The concept of having a framework is to ease the job of the developer in developing the client and server-side requirements using a common discipline.
Interesting finds for AJAX with the .Net in mind: AJAX.Net and Telerik… although the latter is not free…

New Pictures Re-organized

I uploaded some new pictures and re-organized a bit. Hope you like them. I am using a Canon PowerShot A80. It’s a point and shoot camera with some advanced features here and there. Pretty smart. I am not really a professional photographer but I like taking pictures. Someday, when I finally have an SLR, I’ll make photography a serious hobby.

Me as a Father — Thinking Aloud

I have two kids. Boys. Both are attending pre-school. They like toys, playing games (with quarrels in between) and they love going to school. I want my children to enjoy their childhood life. I give them the best I can when and where possible. I teach them about life and about how some things are good and bad; how some things are easy and difficult; and how some things are meant to be the way they are.
I want them to feel good about themselves. I want them to be confident and proud about what they know and can do. I can probably influence their growth, guide them and contribute to making them the best citizens they can become, but I can never control their choices. However, I can teach them about the good values to treasure, share and keep; give them pieces of wisdom to guide them in their life as they grow old; and perhaps even share my knowledge and skills to inspire them of what they want to do when they grow up.
It is tough to be a father. You have to be a model to yourself, your wife and to your kids. They all look up to you. Even to the most shy, a father has to be brave and strong for the kids. Even to the most introvert, you have to learn to speak up and fight for the kids. Even to the most selfish, you have to learn to give and share for the sake of the kids. I am not the best father in the world, but, at the very least, I aim to be the best father to my family.
I know they are proud of me. I know they respect me. I know they love me. And those are the best things a father should know… the best things a father should keep… and the best things a father should never lose…

Re-programming My Body Clock

I am working on a graveyard shift lately. I have to adjust myself to the new work and sleep hours. But most important, I have to adjust to the new meal times. Dinner becomes breakfast, midnight snack becomes lunch, breakfast becomes dinner and lunch can be skipped as I sleep from morning to afternoon. If I stick with the original meal schedule as the rest of my family, I might gain too much weight. I guess it’s one reason most graveyard shifters gain weight.
Anyway… I can control the meals. No problemo. But it’s the sleeping I should work on. Takes a little more time getting used to… Hohummm…

Building Your Own Framework

There are a lot of "frameworks" available out there for .Net developers to use. Examples are the Microsoft Enterprise Library, Spring.Net, NHibernate, the Castle Project and Rockford Lhotka’s CSLA.Net. Although these products have various offerings and different target problems to solve, they are essentally called frameworks. These frameworks help fast track development by providing core features and functionalities that may, otherwise, take time to develop. They have their advantages. But they may also be traps that designers should be careful about.

I don’t really intend to re-invent the wheel, but, I prefer building my own framework and similar "utilities" as some developers would like to call them. I base my frameworks from these existing products, not exactly like re-inventing the wheel, but rather with the intention of simplifying the wheel.

I also like the fact that the frameworks I create are named after the enterprise it targets (<company>.Library). There is a sense of ownership and it can be customized easily to adapt to the capacity of the enterprise’s IT organization. I also like the fact that the frameworks I create can be easier to use, maintain, manage and support. They are also flexible and, likewise, extensible by design.

My framework, like the other frameworks, has its own pit falls. It has the same problems as the other frameworks. The most important consideration is the fact that better technologies always get invented even while you write your own framework. For example, the currently coined ADO.Net vNext promises its own entity framework competing against Spring.Net and NHibernate. ADO.Net vNext is new, but it is the direction of .Net.

The problem that ADO.Net vNext solves is the direction of the developer community in general. Most Java developers have been embracing this model for a long time. I am not sure yet, but the possibility is high that, in the end, .Net designers should highly consider using it instead of Spring.Net and NHibernate regardless of who is mature or not.

Why do I write my own framework? It’s simply because I want to stick as close as possible to the .Net Framework. Not that I avoid third-party products. But if you can, why not?

Microsoft Office 2007 101

The Microsoft Office 2007 is a challenge to implement simply because of possible user training requirements. This is primarily because of the new UI and the new navigation interface called the ribbon plus the new behaviors and features that highlights the collaborative capabilities of the new Office. Users might find this article from News.com helpful.

Abstraction and Data

The principle of abstraction in software design is to extract and separate information in to pieces of storeable or workable data and rules: in that sequence. The ability to identify data is crucial in abstraction. The ability to identify rules becomes natural in a later process and may depend on the designer’s self developed style.
  • Input – these are the data that are identified in the requirement as directly provided by something external to the actual software. Input may also be something that the software itself intends to pickup or gather from pre-determined stores.
  • Parameters – these are the data that serve as the conditions by which data may be sourced, processed and delivered. Parameters are often part of the configurations or the givens in the requirements.
  • Output – there are the data that serves as the expected results of the software’s processing of the Input and the Parameters through a set of rules. It is most important to know the Output. Otherwise, the whole point of abstraction is lost.

Abstraction is strongly about data and identifying them. It’s not much about what you plan to do with them. What matters is that, in the first place, you know about them.

Abstraction Guide 101

The basic steps of abstraction start with separation — specifically, the designer’s separation from technology.
Given the business and functional requirements, designers tend to translate items as parts of a software product. This is natural. It in fact explains why translation is the fastest approach in software design. However, this is prone to the following pit falls:
  • When operational issues come in, the software may lack manageability and maintainability;
  • When technical support and enhancements come in, the software may lack extensibility and flexibility;
  • When the enterprise starts to grow and change, the software may be difficult, if not impossible, to keep up to date.
In order to avoid these problems, the designer must first distance him/herself and start evaluating the current and future needs of the business. In most cases, the enterprise has year long plans of its future IT direction. Even for a software product, the company may know beforehand if it is a long term or a short term investment. The decision of the designer to build a software product in-house, or to purchase an existing platform product in the market, is driven by the knowledge of what ventures the organization intend to value most in the long run.
For example, if the enterprise needs an integration/interface solution, but might need it only for a specific application, not necessarily as something that will strongly drive the business, purchasing webMethods or Microsoft Biztalk Server might be an overkill. However, when the business eventually has plans of relying on it, like as a messaging hub, that will serve many important aspects of the company’s business operations, financials and reporting, both internally and externally, a little extra budget for the established products and technologies in the market may be considered.
So where does software design by abstraction come in? The actual abstraction comes in when the designer knows for a fact that he/she can think small or think big. The target size of the product should help evaluate how much simplicity or complexity may be introduced. It helps the designer decide how compact or how distributed the resulting product would be. It, likewise, helps the designer decide how to justify and fit everything within budget and within the capacity of the enterprise (development, operations and support; success, growth and expansion).
The separation from technology does not stop there. The designer continues to separate him/herself further from technology as he/she splits, slices and separates the requirements from each other. Each piece and bit of the requirements are variables which may be the:
  • input;
  • parameters;
  • rules; and
  • output.
All of these may be easily translated or mapped in to their corresponding software parts at a later time. How they are classified, categorized and organized matters when storage and activation decisions are to be made. Some of these variables are configurations, some data/information, some deliverables and still some are actually rules, logic and plain old common sense.  Some are stored in files, some in a data store and, still, some in the programs themselves.
The designer may then continue to separate the variables from each other preferably without breaking their links and relationships. If in case those links and relationships are broken along the way, the designer must be able to conceptualize the ways and the means by which they may all be linked and related back together. These conceptualizations, in general, are made easy, nowadays, with the help of known models, patterns and best practices.
Abstraction is a process of separation resulting to an "explosion" of the requirements in to their equivalent technical artifacts. The best results are achieved when the designer is not focused on technology, but rather, when the designer is focused on the enterprise: its business and its future.