We can extract information value from maintenance and legacy code. Legacy code contains lots of business rules. It also contains lots of level 3 design information.
Level 3 Design Information
Bit fields, Boolean fields, types, status variable, and enumerations all contain design information that can be collected into endemes. For example, int Microsoft Great Plains, the AF40110 table contains a whole series of flags that can be combined into an endeme set, as does the CM00002 table,
The CPO40001 company table contains type and flag information related to approvals and variances. The FA00100 table contains property and asset type information. The FA00200 table contains depreciation types, indicators and flags. The FA45000 table is filled with all sorts of types which could be combined into one or more endeme sets related to retirement, transactions and year start and end status and types. And so on. IN Microsoft GP I have identified about 3000 columns that could be combined into and managed as information using endemes.
Each endeme set thus extracted is a piece of information design which can ten be ported to new programs during application migration efforts. This is because each endeme set aggregates a group of concepts that operate together in combination.
As a Maintenance Programmer
This holds true with each database and application I have worked with as a maintenance programmer. One of the challenges of maintenance programming is that you can not break the functionality of the applications because the application is usually in production and real users are using it and real companies rely on it. In order to refactor legacy programs you need a serious reason to do so. Information oriented software development provides that reason.
Legacy programs exist at level 1 and level 2. Refactoring them to extract and exploit level 3 allows them to be much easier to maintain in the future, allows them to be much easier to extend in the future, allows them to be much easier to migrate in the future, and allow them to be much easier to test in the present as changes are made. In addition, refactoring portions of them to level three will extent their life.
Here are the 11 key relationships that businesses must handle properly to succeed.
- Relationship with technology — technology, adaptability, design, innovation.
- Relationship between quality and growth — balancing quality and growth.
- Relationship with people — customers, employees, vendors, clients, development.
- Relationship with with self — organization, integrity, internal metrics, vision.
- Relationship with with talent — managerial & employee talent, hiring, training, compensation.
- Relationship with with cash flow — profit, revenue, health insurance etc.
- Relationship with with capital — capital, investing, investors.
- Relationship with with data — information <-> data <-> internet.
- Relationship with with the market — new markets, competitors.
- Relationship with with the future — planning, risk, uncertainty.
- Relationship with with society — regulation, social media, reputation.
These 11 relationships come from the Business challenge endeme set below
ABCDEFGHIJKLMNOPQRSTUV|lt Label complements num descriptive
A]C-E- -T- |A. Adaptability/tech D tech->u 2 Technology/technial infrastructure/adaptability/embracing change
[B] I P R |B. Bottom line H money->u 1 Increasing profit and revenue/margin erosion
[C] -M- -R- |C. Customer V u->cust 3 relationships/loyalty/marketing/service/insight/latent needs - Business managers must properly identify the needs of their consumers or business customers/Customer experience/clients
[D] |D. Design/innovation A u->tech 0 analagous to energy vs acceleration
-D[E] |E. Exploding data J data->u 1 data explosion/data to informtion conversion
-C-[F] |F. Funding M invest->u capital
[G] |G. Growth Q G/Q? 1 Business growth/scaling/globalization/multiple versions
[H] |H. Healthcare B u->money 1 insurance coverage
[I] -P- |I. Integrity O metrics->u 3 Internal metrics/integrity/performance/speed vs quality/metrics and integrity/trust
|J. J-? E u->data 0 information to data conversion/artificial creativity/representational interfaces/reports/dashboards/internal reflections on the internet
-C- [K]M- |K. Know Market N mrkt->u 3 knowledge/the market/the competition/protecting market share
[L]M- |L. Leadership T ldr+wkr 2 management
-C--F- [M] |M. Manage finances M u->invest 3 Financial management/cash flow
AB- -M[N] |N. New business K u->mrkt 3 Attract business/marketing strategy/adjacent markets/time to market
[O] |O. Organization I u->metrics 0 structure/incentives/organism/ideas/vision/mandate/governance/internal churn/mining IP
[P]R- |P. Problem solving U event->u 2 and risk management
-B- -G- [Q] |Q. Quality G Q/G? 1 balancing quality and growth
[R] |R. Regulation S old/new? 3 and compliance/government
-B- -PR[S] |S. Social reputation R new/old? 2 reputation/social media/publicity/Brand/marketers with analytical skills and digital media savvy
-C--F-H- -PRS[T] |T. Talent/Staff L wkr+ldr 3 Talent/hiring/recruiting/competencies/people
-P--S[U]|U. Uncertainty P u->action 2 uncertainty/Planning/Strategy/long term/short term/tool box approach
-E- [V|V. Vendors & employees C vend->u 1 career path for techies/advancement/training/learning/Vendor, Employee and Supplier Engagement/Vendors
+- A. Adaptability/technology
+- technology -+- D. Design/innovation
+- x-ware -------+ |
| | growth/ +- G. Growth
| +- quality ----+- Q. Quality
inward ------+ +- I. Integrity
| +- self -------+- O. Organization
| | |
| | +- L. Leadership
+- human --------+- talent -----+- T. Talent/Staff
| +- V. Vendors/employees
+- people -----+- C. Customer
+- N. New business
+- the market -+- K. Know Market
+- the industry -+ |
| | +- E. Exploding data
| +- data -------+- J. J-?
outward -----+ |
| +- S. Social reputation
| +- society ----+- R. Regulation
+- the world ----+ |
| +- U. Uncertainty/planning
+- the future -+- P. Problem solving
+- B. Bottom line
+- BH ---------+- H. Healthcare
money --------- BHFM ---------+ |
| +- F. Funding
+- capital ----+- M. Manage finances
A. Adaptabilty/tech challenge endeme set:
B E I R |. LEGACY TECH Legacy technology - endematic extration of information entities
R T |. RIGHT TECH correct technology to apply to somethng - endematic choosing of technology
I S |. SCALING scaling and infrastructure - ? - IT no IN
E T |. EMBRACE CHANGE training and embracing change - endeme created ad hoc teams to advocate and teach
I M |. INTEGRATION integrating systems - endematic data integration through data semantics
F N Q |. NEW QUESTIONS new features/questions/dashboards - endematic glomming of databases
F P |. PROCESSES support of new/changed processes/flows - ?
A F R |. DEV FOCUS technology development focus selection - endematic resource allocation
L N |. NEW/LG BALANCE balancing resources: legacy vs new - endematic ROI and resource allocation
U |. USEABILITY making sure people can use it - endematic proxies and wrappers
D M V|. MIGRATION migration from old to new systems - endematic data version integration through data semantics
I. Internal metrics challenge endeme set:
qualitative software development metrics?
J. J-? challenge endeme set:
information to data conversion
internal reflections on the internet
data production for search engines
K. Know market challenge endeme set:
|. adaptability to markets – endematic niche focus, and market direction resource focus
O. Organization challenge endeme set:
|. software and technology re-use – endematic software repository & can endemes make software easier to reuse? – endematic source code analysis
|. document and knowledge re-use – endematic document repository
|. incentives, clear ‘policies’ – endeme set: keep job/make no mistakes, take risks/investigate opportunities, cost savings, personal incentives, budget/project based, structure/department based
|. teamwork, team mutual knowledge – endemes to show each team member about the others, and which tasks to assigne each
|. fluid organization – endematic ad hoc team building
P. Problem solving
Spot the key problem
T. Talent/Staff challenge endeme set:
corporate culture fit
SQL queries may really be a form of information request. Embedded in the implicit need for a SQL query may be an information question or request. How do I identify the information question asked in a query?
Is it possible to extract the information request from the query itself?
There is generally a business need which results in a request for a report which results in a SQL query. The information request may be in any number of places:
- The information request may be only in the mind of the person who looks at the report and interprets it. In other words in this case, the conversion from data to information occurs in the mind of the business person. In this case, you will have to ask the business user how they figure out the meaning from the report.
- The information request may be only in the layout of the queried data on the report pages. In other words the conversion from data to information occurs in the layout code of the report. In this case, the report code will need to be parsed in order to determine the relationships between the various data elements shown on the report.
- The information request may be only in the query itself which is used to build the report. In this case the conversion from data to information occurs in the selection of tables and columns included in the SQL query. In this case the information request might be extracted from the SQL query. Certain meanings will need to be cataloged for various kinds of data queried together.
- In all likelihood the information request will reside in a combination of two more of the above. In this case, you might parse out the low hanging fruit of the SQL and report layout code, and confirm with the business user
Thus, the answer to the question posed above “How do I identify the information question asked in a query?” is that it depends. You may luck out and be able to determine the information request from the SQL query. Or you may have to dig much deeper into parsing and interpreting the report code and asking the business user how they glean information from the report.
Software development is dying because software development has failed to build the tools necessary to work at level 3 or level 4. Therefore when people and employers start thinking about working with information, they think of BI tools, data mining, reports, and big data. None of these are software development and all of these are an approach to filling the need for information.
Our job is to create the tools and the framework necessary for software development to tackle the problem of working with information. Now information and data are two different things. Data is numbers, names and dates etc. Information is numbers names and dates that have meaning. Current software development tools can work with data effectively, and convert data into ad hoc hard coded user interfaces that present it as information, and can place hard coded ad hoc context around the data in the form of xml, object oriented classes, hierarchies, JSON, and relational database tables.
Our job is to create a framework that will allow software developers to process the context itself in a non-literal systematic way. So the equivalent of members of objects, object hierarchies, tables, relations, columns and tags can all be processed, worked with and integrated. I am doing this by characterizing data with endemes in a technique that I call data semantics. This will allow software development to move into Level 3. Then I will characterize organization schemes using endemes and data semantics. This will allow software development to move into Level 4. Data semantics is a process of identifying the context of a piece of data by building an endeme set that can be used to characterize its meaning at a low level of the OO class hierarchy. i.e. simple (leaflike) members.
This should turn software development around and bring it into the information age. Software developers will be able to out-compete the data miners by providing a follow-on step covering not only the mining of data but the storage and further processing of the information once it has been mined out of the raw data. Software developers will be able to out-compete the report writers by crating reports that respond to user needs and that can be extended and modified as desired, that can be built using more natural langauge like requests and that will have an internal tendency to focus on (and tend toward) what user’s real and changing needs are. Software development will also be able to provide more powerful BI algorithms, and will entice BI people into software development, as BI people will be able to ask better, more powerful, and more usable questions of their technical data by writing programs to do this. In addition, BI will benefit by having a longer and more useful workflow, in that their results will not just sit in a report, but will be usable in further studies and analyses.
This is how we intend to turn software development around.
Programmers could build mutual languages for talking with users. One of the difficulties of programming is figuring out what the users are asking for. Programmers base their understanding and therefore their terminology on Level 1 and Level 2. Users seem to operate at Levels 4, 5, and 6 (Knowledge, intelligence, and creation). When we develop Level 3 programs and designs we develop mutual languages between users and programmers at the same time.
To see people committing technological suicide, and to rope me in as being part of it, leads me to feel nausea. I feel like throwing up when I have to build reports. Reports are a form of technological suicide, reports are where data goes to die! Instead of being able to use the information extracted in the report, it goes onto a piece of inaccessible paper or goes into an inaccessible format. yock.
Instead of using the information that reports create to build this stack upward, the information just sits there. My focus is to build this stack, and to have to know that my energy is going to push technology in the opposite direction offends me. There I said it. It is a vile and unconscionable waste of my customers’ mind space. It leads to them thinking that they can not work with the information once provided, using programs that can be built to meet their needs. It leads to deadening of the soul and the senses. Also the business rules are essentially buried in the database. Reports are bad.
I go back and forth between wanting to cry and wanting to vomit.
Users see the wrong things so they can’t ask for the right things. Programmers work really hard to convert data to information to show the users based on user needs. These are ad hoc conversions of data to information as data is moved to the UI for users to use. But then the users don’t know how it has been produced and ask for things in the ad hoc information terms the programmers were able to shape things into which are the wrong terms to use with a programmer because the programmer does not live in the world of information.
This is not as much a problem in new development, but this is a huge problem in maintenance development where usually different programmers are doing the development than those who did the original development. This may be part of why maintenance development is so expensive.
Programmers mislead the users by creating a world for them that is not organized the same way and does not reflect what is behind the UI.
My goal is to build a common information world that both programmers and users can use.
Then they can interact more easily, productively and without misunderstanding. Level 3 and Level 4 could be used for this purpose.