Synchronized Innovation


In the early days of computing, the norm was to think about computer-based solutions in terms of hardware, software and peopleware. Although we have evolved to using terms like "IT", "infrastructure", "architecture" and "cloud", it cannot be denied that the basics stay. Think about it: as primitive as it may seem, all else fails, the morse code rules; all else fails, the typewriter is your friend; and all else fails, a hand fan works just the same. If you go back to its roots, regardless of its size and shape, the computer was, is and will always be about the hardware, the software and the peopleware.
 
Over the years, computing industries developed vertically with companies focusing on hardware only, software only and peopleware only products and services. Although vertical focus would remain to be practiced for decades to come, it seems to have reached its peak. Over the past 10 years, companies are bravely venturing back to delivering "computers" in full form complete with the hardware itself, the software to run in it and the peopleware to support them. It is no longer about making devices available. It is no longer about making application programs available. It is no longer about people making the overall product actually useful.
 
The hardware is nothing without its software, and vise versa, but both are nothing without the users and the people behind them. All three should be in place and should work together in harmony. Each one contributes to the success of the other. The progress of one progresses the other. They should all grow and mature at the same time. None of them should be able to overwhelm or, even, underwhelm the other. They should compliment each other. Suffice to say, the interdependency is inevitable.
 
A computer-based solution should be ready for immediate use and to deliver its value in the present time. It can neither be ahead nor behind of its time. What is a device capable of if it can’t run the applications developed to run in it? What is an application for if there is no device available that’s capable of running it? What’s the purpose of both if there is no one who’d actually find the value to use them or to even invest on them? After all, failed expectations are opportunities lost.
 
This is the context of synchronized innovation where, all things in balance, nothing should ever go to waste…

Enterprise Software Development – Planning and Preparation II


The best plan foresees and anticipates the future. And the most complete plan includes contingency or that "plan B" that would save the day if everything else seems to go wrong. Planning the enterprise software development efforts of an IT organization is in itself a preparation for the IT organization’s each and every future.
 
Worst case, poor planning and preparation may result to expensive revamps, retoolings and loss of knowledge resources. We’ve heard of companies making drastic switches from platform to platform. We’ve heard of companies switching core business software products every now and then. We’ve heard of companies reworking year long efforts of migration, upgrades and updates that failed and cost them double or even triple had they started it right the first time.
 
A vision and a mission is not enough. Concrete planning and preparation should be drawn and put into action, little by little or immediately depending on the resources available and the viability of doing so in favor of the enterprise.
 
Planning and preparation, therefore, should result to the following:
 
  • Roadmap;
  • Timetable;
  • Plan A;
  • Plan B; and
  • Enterprise approval.

The roadmap sets the path. The timetable sets the pace. Plan A lays out what needs to be done. Plan B lays out what needs to be done in case plan A fails. And the last item proves the business value of the planning and preparation made.

It’s almost simple. It’s almost easy. But this is just the beginning…

Enterprise Software Development – Planning and Preparation I


The ability of a software development team to achieve true enterprise software development requires planning and preparation. Foresight is a main ingredient of a successful enterprise software development team.
 
What is important to the team?
 
The team should be able to identify what is important to them in terms of:
 
  • Their capacity to provide future support;
  • Their capacity to deliver enhancements at the most acceptable turn around time;
  • Their capacity to advance as the technology itself advaces.

The software development team is the source of the action in terms of making software a reality. While the management, fr example, may have its share of the motivation, the team by itself should be driven by its own energy and spirit.

 
What is important to the IT organization?
 
The IT organization establishes the future of the enterprise’s IT investment. They wholly involve the enterprise to the knowledge and skills of the IT people and the IT community in general. There is no better level of influence available in IT than in the executive level of the IT organization.
 
The IT organization should be able to identify what is important to them in terms of:
 
  • Their capacity to keep raising the IT organization’s value proposition;
  • Their capacity to deliver to the basic expectations of the enterprise;
  • Their capacity to ensure the continuous advancement of the IT organization as the whole IT world advances.

The IT organization, first and foremost, values the enterprise it serves. It is understandable for the enterprise to expect the highest level of perfection possible on its IT organization. This challenge is best accomplished for as long as the IT organization could raise its value proposition and continue to invite investments that add value to the enterprise.

 
What is important to the enterprise?
 
The enterprise should know what is important to them in the first place. They are the reason why there is an IT organization in the first place. Which is the reason why there is an enterprise software development team.
 
The enterprise provides the foundation and the basic principles on while the whole of the IT organization stands. Nothing can change that. For all that matters, its what should be important to everyone else in the enterprise.

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.

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?

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.

A Focus on Abstraction


Abstraction, an an approach in the software design process, requires experience and business knowledge.
 
The experience is not necessarily in the context of experience in designing software. In fact, the experience is usually a hands-on exposure to an existing product which triggers and inspires ideas. For example, an existing dialog form in Windows may inspire the list of parameters in defining the connection strings to the database. Or perhaps, you may find data mapping strategies and techniques from the data mapping tools of Microsoft Biztalk Server, Microsoft SQL Server’s SSIS, HiT Software’s Allora and Stylus Studio.
 
The business knowledge drives the depth of abstracting the requirements. To abstract or to translate? When do you keep abstracting? When do you stop? How do you intend to implement it? How do you plan to support it? Abstraction may be a powerful approach but it shouldn’t be an overkill. Abstractions tends to make the software very advanced and complex. The risk of complexity should be contained within the software so that how it works inside are transparent to the users. At the end of the day, what matters to users is that the product just works.
 
Abstraction may lead to invention, innovation and customizations of technologies. It may lead to building frameworks and architectures that could re-define the future direction of the IT organization. Most of the software products available in the market are designed through a lot of abstraction. Consider the Castle Project’s Windsor, the Microsoft Enterprise Library, AJAX-based products, Netbeans, SAP, etc. Consider also the amount of abstraction needed to achieve specific product features like the new Microsoft Office 2007’s ribbon, Apple Mac OS X’s Spotlight search, Microsoft Money’s user interface, Oracle OWB tools, etc.
 
When you start building your software with the future in mind, consider abstraction as an approach. It might slow you down at first. But in the end, it empowers and enables the IT organization for the enterprise.

Thinking the Software Design Process


Given the business and functional requirements, the immediate challenge is how they can be expressed in to a technical specification. A business/functional requirement may or may not include hints of it’s technical needs — although the presence of such clues may in fact be ignored during the design process. In general, a designer may take two directions in designing the solution.
 
Translation
 
The first approach is to translate the requirements list as items to be developed in a software product. The approach is a straighforward mapping of the requirement to specific software product parts. The intention is to solve the problem directly and immediately along the way. I find this approach most useful in designing UI elements and forms. It is an effective prototyping strategy because it demands a shorter design and development timeframe. Also, it is the simplest to test and audit against the original requirements.
 
For example, if the requirement is to download data from a specific location, the program is developed to download the required data from the specified location. The parallel structure of the requirement and the specification is characteristic of the Translation approach.
 
Abstraction
 
The second approach is to abstract the requirements in to a technical specification. This actually takes translation to the next level because it allows the designer to develop strategies that give easy room for growth and future enhancements. Abstraction requires a lot of conceptual thinking and planning as guided by the principles, disciplines and practices followed by the designer. Simply put, the intention is to solve the problem indirectly but very effectively, usually exceeding expectations after all things are considered.
 
For example, instead of developing a program that will download a specific data from a specific remote store, the designer may create a core application that would allow the user to define various parameters in order to achieve downloading any data from any remote store. In this scenario, the indirect solution is to create the core. The effectiveness is realized upon implementation where exactly the same core may be re-used to process any data source.

Blog Plans


I am planning to write my thoughts on the following topics in the coming days.
 
  • Structuring the IT Organization – a look at an ideal structure for an IT focused organization
  • The Structured IT Organization Process Cycle – a look at an ideal process cycle for an IT focused organization
  • Solution Infrastructure and Architecture – a look at some effective solution designs and practices
  • Designing Applications for the Future – an architectural perspective with the business in mind
  • Enterprise Software Development – a look at some effective disciplines and practices in developing for the enterprise
I am currently collecting data and thoughts on the subjects listed above. Watch out for them…